CodeMiller

Next transaction: 10 influences developing a dev

I’ve heard it said (and tweeted) that if you don’t hate code you wrote six months ago, then you haven’t learnt enough in the past six months.

It didn’t even take one month for me to start despising the ‘fiscal challenge’ code I blogged last year — I admitted it didn’t seem right to me in the original post — but at the time I wasn’t sure how best to refactor it.

Recently I had reason to reattempt the same cash dispenser programming exercise, and I soon realised the best approach was not to refactor my old code at all but rather to start from scratch, taking into account all I had been learning.

The finished product was vastly different from my first effort. While I would still not argue that it is perfect code by any means, I believe the second version has a much cleaner and more maintainable structure with better separation of concerns. Here is a snippet of the new code, representing the same portion of the exercise as what I first posted.

As I mentioned the Haskell programming language in the original post I thought I should try my hand at a more functional solution as well. I came up with a different algorithm for the Haskell version (and was aiming for readability rather than brevity) but this code snippet addresses the same part of the cash dispenser problem.

Looking over the new code I was quite surprised at the degree of difference a few months of experience can make. As this is my first blog for the new year I thought it would be appropriate to spend some time reflecting on what influences or practices have been helping me to improve my programming. I came up with the following:

1. The right learning environment. If you are exposed to best practices daily, you are likely to start to incorporate them into your coding. 
2. Talented technical mentors. It’s much easier to learn from experienced engineers than to try to figure out everything on your own.
3. Using test-driven development. You have to be disciplined to work this way but it can produce leaner, more testable code and encourages a focus on requirements.
4. Pair programming. When you’re new in a team and/or to professional coding it really helps to see how others do things and the standards they apply. I have also picked up some nifty keyboard shortcuts this way. 
5. Exploring functional programming. It makes you think about problems differently and helps you to write better code no matter what language you are using, as I have argued in a previous rant.
6. Learning new languages. Different programming languages have been designed to solve different problems. If you only know one you’re bound to be missing something from your toolkit.
7. Reading informative books. If you’re coding in Java, I can’t recommend Effective Java enough. The Pragmatic Programmer is another worthy entry on the must-read list.
8. Studying code libraries. There’s a lot of fantastic stuff both in standard language libraries and beyond them, but you’re never going to use it if you don’t know it’s there.
9. Practice. It’s all very well to code for work or study, but there are many more opportunities than that. Playing with Android has been fun and instructive for me. Coding competitions and open source projects are other avenues I’d like to further explore.
10. Attending coding meet-ups and conferences. It’s a great way to get exposed to new technologies, new networks of people and new ways of doing things. Special mention goes to Code Retreat; you are forced to delete your code after each iteration so you can truly start afresh in the next one, which is a valuable lesson.

That’s what came to mind for me, but I would be interested to hear what more experienced software engineers would add to the list. Please let me know if there is anything I’ve left out that has helped you to improve your coding over the years.