“Nothing endures but change”, wrote Heraclitus in around 500 BC. I doubt he anticipated modern software engineering practices, but the man had a point. Teams change, requirements change, products change. Our process as software engineers must also change. We talk of “Agile development”, which conjures images of responding to outside change – but our practices themselves must also be constantly reviewed, to cope with external changes as well as to strive towards perfection.
Heraclitus also wrote: “You cannot step twice into the same river; for other waters are ever flowing in”. In my case, I’m stepping out of one river and into another. Tomorrow is my last day with my current employer.
I’ve been here for 11 years, which at the same time seems like forever and no time at all. It’s been a real pleasure working with my excellent colleagues. I’m proud of what we’ve achieved together – we’ve made some really cutting-edge software. I’ve played a small part in the process of revolutionising scientific discovery (and made some pretty pictures along the way).
I’ve been writing this blog in order to put my own opinion out for discussion, and I see no reason to stop now. Talking about stuff is the first step towards changing; discussing the last river can help us anticipate the next.
So, what do I hope my colleagues will do after I’ve left?
- Communicate. Talk more, consider everything, let nothing be so sacred that it can’t be discussed. I don’t mean argue (although a good argument, well managed, can be a good thing). I mean, challenge current behaviour. Talk about it in chatrooms, in blog posts, in the kitchens, in the pub. Come up with new ideas and write them down. Get people invested in a product and its processes.
“Opposition brings concord. Out of discord comes the fairest harmony.”
- Be adventurous. We’ve done our best work when we’ve stuck our necks out. Talk about it first … then do it.
Nobody gets excited by blandness. Choose not to do things because they are easy, but because they are hard (and I bet Heraclitus never anticipated the moon landings).
- Don’t be good enough. That’s not good enough. Be good.
Writing software to a list of specifications is not sufficient. Do you have a list of checkboxes, features which your software must have? Don’t do that. It leads to software which is described as “functional”. The stuff that gets given away free with hardware.
Think instead: Is this good? Will the user be pleased? Will they laugh at their colleagues when they complain about inferior software? Will they barely notice all your hard work, because your software just does it right? That’s good software.
Well, if nothing endures but change, then all art is transient. My own opinions are just a voice from the past to my colleagues, so ignore them or consider them as you will (I’m sure you were going to anyway).
It just remains for me to thank everyone who’s been reading this blog, and listening to my meanderings, for your time and attention. It’s been great having a platform, and I encourage you all to do the same.
Talk; take risks; be amazing. Cheerio!