In the past 6-12 months I’ve learned quite a lot and come across plenty of fun new libraries and applications. Out of fear I’ll trip, bang my head and forget it all I’ve decided to document what I can before my rather fickle brain decides to clear up the clutter and leave me a dribbling mess. You might find this useful, you might not; either way feel free to add your own insights and comments (yes, I’m still not over the fact that I finally got a content wotsit that supports comments)
1. Research is *really* important before starting a new project. At a minimum (and assuming it’s an area you are already familiar with) allow yourself a week or two of googling and pouring over research papers etc. Google Scholar is incredibly useful and allows you to find citing and cited papers once you’ve found one of interest/relevance. Prior research allows you to avoid spending hours agonising over problems other people have already solved and means you can get onto the real value adding stuff much sooner. In terms of building a product this means you get to spend more time working on what sets you apart and ahead of the competition, and I’m fairly sure that’s a good thing.
2. Research is important for supporting your ideas but don’t let it unnecessarily restrain you. By this I mean, don’t let the ideas in the papers you’re reading completely take over your thoughts. Allow room for your own original ideas. In a similar vein, reading paper after paper without applying any thought to them is essentially useless. Have a pen and paper ready and document *every* idea you have before, during and after researching a topic. You’ll probably cross a lot of these off as you go but some of them will be invaluable.
3. As a last point about research, don’t believe everything you read. Peer reviewed articles are usually of a high standard but not always and sometimes when it comes time to do some implementation you discover a number of areas in which papers have ignored potential sources of error or have brushed them off as inconsequential. As I said, research is a useful prop but is no replacement for your own brain.
4. Everyone should have a pen and paper. They’re wonderful things. Ideas come and go and writing them down now is always going to be better than trying to remember them later.
5. Design is important at all levels. From high level component interactions to pseudo-code documenting an algorithm. If you can’t design something on paper then chances are it’s too complex to do it for real. Often times when a design doesn’t quite seem right it’s easy to say “Ah, sure I’ll it out when it comes up”. The problem with this is that if you can’t sort it out now when you’re clear headed then how could you possibly hope to solve it when you’re up to your eyes in implementation details. An inability to design something on paper can either mean you’re too tired/distracted or the solution is sub-par. In both cases it can be useful to go away from the problem and do something else for a while.
6. The Zen of Python should be renamed The Zen of Everything and made mandatory reading for everyone over the age of 5. Once that is done it should be beaten into every Java programmer that has ever written ‘} catch Exception {’. As soon as they’ve been soundly trounced, we’ll deal with the C++ folk and their use of assert().
7. Test! Test! Test! I know…it can be boring…really boring in fact, but it is absolutely critical for any serious application. Unit tests give you confidence in your application which is just as useful as the quality they add. Having the discipline to write tests for everything is something that still evades me but even with the amount I do I can see the benefits. Believe it or not, testing actually allows you to be more productive as you spend less time worrying and manually running code. For Python I’ve found the inbuilt unittest module to be excellent and fulfills most of my unit testing needs. The only place it falls down is the lack of mock object support and this gap is filled nicely by pymox from Google.
8. Write your tests *first*. This was an odd one for me when I started doing it but was one of the most profound revelations in my programming career. Writing the tests first is somewhat related to the design I mentioned in step 3. If you can design an algorithm completely on paper and then have the mental clarity to write a test that documents the results you expect, then chances are you’re on to a successful solution for your problem.
9. There’s more to testing than unit testing. Just because your algorithms are correct doesn’t mean your results are. Higher level design problems aren’t the target of unit tests and can easily go unnoticed. Test the entire system from a set of known inputs with known results. This can be more difficult and tedious to set up than unit testing but without it it’s hard to be fully confident in a solution.
10. Expand your knowledge beyond whatever field you currently specialise in. RSS feed conglomorates like PlanetPython or one of the others are excellent for this. By following these you can find a wealth of information on subjects related to your interests but slightly away from what you might delve into yourself. Looking into these other areas can keep your mind ticking over and provide plenty of new problems to think about and tools to solve them with.
Righty, well that’s that taken care of. As I said, comments are welcome. In my next post I’ll go through some of the cool new apps and libraries I’ve come across in the last few months.