So this came to me one morning last week when I was thinking about programming:
- Find a giant
- Get up on to its shoulders
- Have a look at your problem from up there
- Get the giant to help you
This rather barmy heuristic is basically teaching you that when approaching a new programming language, in fact programming in ANY language, you should get on with working out how to do a particular thing at the conceptual level rather than reinventing the wheel. If you attempt to build things from scratch you are doomed to the impossible task of building a giant on your own. Far better to appraise the work of others (use libraries, frameworks etc) and trust in those so that you can get things done.
Sometimes there are barriers – proprietary libraries etc – but usually even with these someone will have got a bit pissed off with some proprietary code that was in their way and written something open source for you. So sub-rule number one is “It is okay to reinvent the wheel if you encounter someone blocking you with an overly restrictive license or cost”. That is the point when reinventing the wheel will be worth your time.
Consider the art of programming in general and this is the concept that drives all code – this is the killer feature of all new languages if you think about it. What is that drives you to consider a new language? You want to perform a particular task (or cluster of tasks) a little better than before. Find the best tools possible, use them, compose multiple tools if you need to, and build things. Do not worry too much about whether the implementation of technique X in library Y is slow or clunky: just use it to create code that works and then worry about the optimisation later. The chances are that someone will have already done it by the time your thing is made.
There are general principles that will guide your way in software development. Learn these, not the trendy features of the latest hip language to enter the ring. Take Swift as an example, this is a programming language designed to abstract certain features of Objective-C and make it easier to program iOS and Mac OS X applications. This means that if you program applications for those platforms, use swift to do just that: don’t worry too much about how it does it. If you’re still worried about how things are done, use Objective-C.1
When I write code, my job is essentially the following:
- Make something that works.
- Make it work better.
- GOTO 2.
Eventually I will get to make something new but the major part of my job is to get what exists working better. Getting it working is just the start; there is very little new under the sun and so even that start will usually involve getting something else working.
As a mathematician, I quickly cottoned on to not having to redo all the previous work – as long as your foundations are sound. But when it came to the programming aspect of my career, I was prideful and regarded developing pre-existing code as a sign of weakness. This was stupid of me because the idea was to save time and meet business objectives, not to give me the warm and fuzzy glow of building something beautiful. It might have helped if the code I received had been better maintained, but you can only play the game with the cards that you are dealt.
Despite learning that lesson, I would still advise against being entirely pragmatic in terms of programming. You should be open to new ideas. In business, the person who works diligently and skilful with the tools available to them will gain an advantage, but not for long. All advantages in life are temporary rather than permanent, that’s why you have to keep training. This is where I failed because I didn’t demonstrate to my managers the reasons for keeping closer to the cutting edge. While you can’t adopt new methodologies and technologies2 for the sake of it, you have to accept that things move on for a reason and if you get left behind, more fool you.
I once had a boss who despised the Ribbon interface introduced to Microsoft Office in the 2007 edition. He would pontificate for hours about how terrible it was and how it took up loads of the screen and how it was just there to justify the existence of 2007 and so and so on until we all fell asleep. When I pointed out to him that I liked it because it helped me to find things more easily and that I’d learned several new capabilities because of it, he didn’t really care. He thought the new interface was no good because he already knew what he was looking for. He didn’t need new ideas. But what happens when the thing he always looks for gets superseded by something faster and more effective?
At first sight this appears to be a sticky situation. On one hand, you have to get on and make things. On the other, you need to make sure that you know how to do things in the best way possible so that other people don’t make better or faster or shinier things. But in fact, I think my first bit of advice is the most important: Make something and then make it better. Persistence trumps talent, deeper understanding brings forth long-term success, and so on. Try, fail, fail better.
That is the philosophy I try to apply to everything. I never pretend to wholly understand anything3, but I am damned if I am going to let that stop me from being curious and making things happen. It is what I try to do on this blog, in waves at least. I try to write regularly in the hope of getting better. If you look through the archive, you will see long pauses where I lose faith, but it is something that I always come back to. I even go back to old posts nowadays (that GOTO 2 line again) in an attempt to make them better. Sometimes I think about what a particular post wants to say or means in the greater scheme of things, but a lot of the time I just do it.