In some ways the book is as much about documenting the early careers of some famous programmers as it is reflections on the craft of programming. In most cases these people are the exception to the current norm. Apart from Brad Fitzpatrich (of LiveJournal fame) they are authors of older or experimental software using older languages and techniques. The book documents how many have had the luxury of developing ‘ad-hoc’ with limited or no commercial deadlines. Consequently, there’s limited insight on pragmatic use of current development tools, languages and methodologies under commercial pressures. After reading the book, I thought there’s scope for another book reflecting more on the current craft of programming.
Nevertheless, there were some themes I found interesting that particularly resonated with my past experiences of working in teams…
- It’s rarely a good idea to restart and rewrite a large project. It’s usually extremely difficult to fully re-implement all the original features. It’s often better to replace parts gradually.
- Starting on one platform with a view to doing others later can result in sub-standard subsequent implementations. If you can, it’s better to write all platforms simultaneously.
- Inexperienced developers often promise that if they spend lots of time on an initial (usually very complex) framework then the rest will be easy when in fact it’s often better to do without the framework and ship quicker.
- The ability to communicate well can be just as important as programming skills. This manifests itself in ways such as producing documentation, empathy with client and code readability.
Having spent most, but not all, of my career using object oriented languages rather than functional languages, it was interesting to hear the veterans’ opinion that OO languages might be holding us back. There was an observation in the book that OO hasn’t realised its promise of re-usability. It was mentioned that this lack of re-usability might have come through being able to hold state held within OO objects. [Functional languages have no internal state and it’s easier to mix and match algorithms.]. I am not so sure this is the reason. I think it’s more to do with the uncertainty and variability of future requirements and, as the book mentions in another context, the developer mentality/comfort of writing anew rather than understanding and re-using someone else’s code.
It was also mentioned that current popular programming languages will hold us back when it eventually comes to running on tens, hundreds or thousands of multi-processors. New language semantics will be needed to describe what runs where together with the ability to map exact memory locations in ways that older (functional) languages provide.