Margaret Hamilton with some source code, maybe from the Apollo Guidance Computer project. The code was woven into rope-core memory (left). Changes to that were not easy. Astronauts used the interface (right) to access AGC functions
Code is easy, I was told, because it is mutable – it will always be growing and changing – hopefully growing in capability, not in complexity. It is hard because you can paint yourself into corners – you create the maze that you solve and your tools can become your torture devices if you are not careful.
Here are a few things I learned in that respect from revisiting Practical Object-Oriented Design in Ruby (POODIR)
- The practicality comes from a succinct set of ‘retries’ on individual concepts, enhancing them with each iteration, finding the new advantages and flaws; in other words the way a Developer learns and grows. It is as short as this format could allow and still cover the territory of object oriented design and test
- It centralizes the dichotomy of object oriented design – composition versus inheritance but in the end emphasizes that the Message is what matters – communication between structures is what leads to joy in development
This is not a prescriptive journey, the core concept is that the reader understand the trade-offs and why they continuously re-appear in every development process – software development is a holistic process and choices are pragmatic – meaning they are made based on the best information available at the time, and on the fundamental assumption that software will be refactored when new information comes along.
The book is no more static in its approach that a development project and no more judgemental that a good fellow code reviewer.
This is a read for a practising professional that has been heads-down a bit too long, or a new graduate who wants to understand some of the more enigmatic comments on their pull requests. It can be read on a weekend and will broaden perspective. I appreciated most the last sections on testing and behaviour-driven development
Some of the main metrics that the author emphasizes is ‘cost effectiveness’, i.e. time cost now and time cost in the future, and Joy, which is measured in the ease of manipulating and traversing a code base to adapt it to new capabilities. These are the two most meaningful things a developer can measure, since they impact every day of their careers.
Three big takeaways:
- Test the behaviour of Object through their public interfaces. Question the existence of extensive private behaviour in a given moving part of your design
- Understand that their is a spectrum along which you make architecture choices every day – between composition and inheritance, between now and the future. The balance is struck in terms of time invested now versus time needed for future changes
- Code is mutable – it will change, and you may or may not be the one to have to change it. Make this process of refactoring a joy, rather than a pain through self-documenting architecture, interfaces, and tests
After watching The Martian you might be craving more realism, more Mars, more mission control, more space exploration, more survival stories, or just better acting. Here are a few documentaries, books, and other movies and how they are related to The Martial, aside from the usual “same director” and “same Matt-saving”
PDF Slide Deck: Let’s Talk Energy March 2015
Think about the last time you found out something really interesting to you online – was it something you were even aware existed when you started looking, or was it a series of links that brought you further from your starting point but closer to what you wanted? Were you even looking for it at the time or did it ‘find’ you through your connections your other interests or a combination of those? Like the perfect Christmas gift, you never even knew you wanted it till you had it.
The fuzzy side of data is probably uncertainty. Here is a quick overview of viz methods for showing what you don’t know visualisingdata.com: Visualizing Uncertainty
On the left, an aspirational watch, the Sinn265 mechanical with special materials, special mechanical movement and special, ridiculous price. On the right, the Seiko sna139 for the less that 8% of the price…if I could put one together from parts!
If you program and do interfaces, you might like watches. It is a distillation of function and interface and taste. It’s technology as your personal signature and of course, the Very First Wearable.
It might just be a reminder that not everything has to be ‘smart’ but no so smart looking.
You don’t need one any more, but you may want one because of it represents – a self contained universe of design thinking and craftsmanship that solves a problem that has been solved many times before, but in its own unique way.
Since it is a personal signature, when you find one you want, you want it. And when it is no longer available, you have to start thinking, ‘how badly do I want to make this happen?’ The answer may depend on whether you want to pick up a pair of Tweezers.
Here is an album was my first experience some time ago in making a watch I wanted from a few different pieces
Like Vasquez says: “Anytime, Anywhere”
tl;dr: here is the codepen
Expect all network communication to be asynchronous. You don’t know when requests will come back to you, and you likely have no idea what order they will arrive back. So you write your code asynchronously, same as you do in real life:
“Look, just get back to me when it’s done, ok?”
“Sure thing, I’ll call when it’s ready”
That’s all a Promise is – that conversation and that commitment. And they are a great design pattern to restore some sanity to asynchronous code.