Quotes

To learn something new, one way is to go and experience it. Over the next hill. This is why the young depart and travel. Or, someone might have gone there for us. What they have learned comes to us as a story, a lesson at school, a Wikipedia entry, a book. Aristotle and Theophrastus go to the island of Lesbos, they minutely observe fish, molluscs, birds, mammals and plants – they write it all down in books, and in doing so they open up the world of biology.

White Holes by Carlo Rovelli

While the book is primarily about physics, specifically white holes, there’s lots of references to literature and religion mixed in that makes it about so much more than just that. It is a really enjoyable book for that alone. The specific subject the book is about is white holes, a sort of opposite to black holes. But it is about so much more from the general scientific process to how literature reflects the natural world. For example, Dante’s Infermo is brought up over and over in likeness to someone travelling into a black hole.

With a little attention, we can also account for the fact that we are inside a black hole just by looking around. Here space is spherical, just like it is outside, around the horizon – but outside, with powerful enough rockets, we can move (upwards) towards larger spheres. Inside, on the contrary, whatever we do we will find ourselves in ever smaller spheres. The

Taking notes, in my opinion, is the best thing one can do for themselves. Writing is a form of thinking, and writing manually, in an analog manner, elevates the process. It has a positive impact on your well-being. It’s akin to working out for hours and then returning home to relax. You know your body hurts, but it feels good. Writing has that same feeling for me.

https://arslan.io/2025/02/24/plotter-notebook-system/

I wouldn’t confine this to analog only but writing does help

In our search for measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate.

This is one of the main points of the book in terms of what you should be measuring. The key thing all this achieves is making changes faster. If changes can be made quickly then developers can ship much easier. You can deploy and roll back changes faster means they’ve less risk when they go out. This gives you speed. If you’ve to take days or weeks to think about what change you can make and how you need to make it, then it slows down everything and in fact increases the risk of the change. Instead look to reduce the risk and increase the speed. Proper monitoring for the changes should exist so they can be detected and rolled back quickly.

In continuous delivery, we invest in building a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve.

A key goal of continuous delivery is changing the economics of the software delivery process so the cost of pushing out individual changes is very low.

For lots of metrics you should avoid making a particular metric the goal as you’re likely to end up with everyone optimising for that. This is probably no exception so you’ve to be careful

For all the gains, few outside the office shared the same regard for the group’s approach. When Berlekamp explained his firm’s methods to business students on Berkeley’s campus, some mocked him. “We were viewed as flakes with ridiculous ideas,” Berlekamp says. Fellow professors were polite enough not to share their criticism and skepticism, at least within earshot. But Berlekamp knew what they were thinking. “Colleagues avoided or evaded commenting,” he says.

Over and over throughout this book there are many instances of how success never was really obvious. Nowadays the fund is one of the most successful ever but back then it was far from obvious that they were making any real headway - most believed it was a curious idea but wouldn’t unseat the “professional” bankers and traders who would make most of the money forever

Berlekamp told Simons he was unsure what to do. Simons couldn’t understand his indecision. “Elwyn, when you smell smoke, you get the hell out!” Simons told him. Straus closed the brokerage account and shifted their trades elsewhere. Months later, Mahlmann resigned from Stotler and the Chicago Board of Trade; two days later, Stotler filed for bankruptcy. Eventually, regulators charged the firm with fraud. Simons and his firm had narrowly escaped a likely death blow.

Another quote is this one where they got caught in a near miss of the collapse of Stotler Group, a trading firm they did a lot of business with. If the didn’t move their trades, they probably would have had

When the U.S. transferred the canal to Panama in 1999, the waterway’s original locks from 1914 were almost obsolete as they were too narrow for many U.S. Navy ships. Panama embarked on an overhaul to expand canal capacity and boost profitability. It invested more than $5 billion to build larger locks that boosted revenue and the number of ship passages to as many as 36 a day. That sparked its transformation into a vital link for global trade that also triggered investment at U.S. ports to handle the larger tankers going from one coast to the other with oil and liquefied natural gas. The canal now generates some $5 billion in annual revenue. The government keeps about half and the rest covers operating costs and investments.

https://www.wsj.com/world/americas/panama-canal-us-american-history-e79a34f0

It cost about the same to renovate the canal in 1999 as it brings in today in income. Taking inflation into account it cost about $9.47 billion back then in todays dollars. Not a bad return on investment

I guess the moral of the story is you can’t just build something once and assume it’ll be there forever, you have to keep reinvesting over and over to keep up with the times or else people will find other ways around it.

I’ll elaborate my earlier rule of thumb: anyone should be able to bring in a clean machine, check the sources out of the repository, issue a single command, and have a running system on their own environment.

https://martinfowler.com/articles/continuousIntegration.html

Sounds simple but so many miss this. Often through no fault of the project itself but through dependencies or version mismatches, things out of date or not installed.

We should reduce the cognitive load in our projects as much as possible. When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly four such things in working memory. Once the cognitive load reaches this threshold, a significant effort is required to understand things.

https://github.com/zakirullin/cognitive-load

It’s a handy rule of thumb to keep in mind when doing anything, not just writing code. In code, try keep things at the high level and not to next details within details too much. If you can make things like functions or files encapsulate all the logic they need and be as standalone as possible then the developer can ignore much of the world going on around them and focus just on the changes here. However if the function has side effects on outside code or relies on many different pieces to function then anyone will struggle to understand it.

It’s something to keep in mind when you see large files and why things should be kept fairly simple. Again it is a rule of thumb and there are situations where it can be broken but in general try keep cognitive load low

The past while I’ve started to take a random quote and put it on this blog. Sometimes there’s commentary and sometimes it is just the quote. I’m not sure how useful this all is to the random person going by but the target market for this website is me, not anyone else. The purpose is to build up a habit and an ability to write and to communicate. So this is what this is about

It is inspired heavily by a few different sources, namely this post about creating a linkblog by Simon Wilson and Marginal Revolution by Tyler Cowen. In both of those, while being blogs, the main content is usually short pieces or links to other places on the web with short sentences or paragraphs exploring the link. I’m thinking to start at a relatively easy place that is what I can do.

The easiest source for content on this is using Readwise daily review. In that it gives me 5 random quotes I’ve saved over the years. The thing is I never really use those quotes for anything and reading them doesn’t give me much benefit. Read anything about how to improve your learning and the most beneficial ways is to do spaced repetition and to make use of the learning - put it in your own words. So that is what this blog is about. Taking those quotes and putting my own words below them. Much of the time there won’t be much said and what will be said won’t make much sense. But

One of the differences between regular developers and software craftsmen is that software craftsmen are on a mission. They are on a mission to make things better, to deliver value to their clients, and to inspire people around them. They are not afraid to lead the way and drive changes. For software craftsmen, striving to always do their best is just a natural state of mind.

The entire premise of the book is about getting us to look at software as a craft. So take the time and energy to make things better for everyone rather than just seeing it as a job to get done and get to the next thing. Taking time like this leads to better results in the short and the long term

The pioneers of the Industrial Revolution valorized precision, and as the revolution gathered speed, requirements for precision grew ever more stringent. In the 1770s, James Watt proudly declared that the cylinders of his steam engine were bored to the precision of 1/20 of an inch. By the 1850s, the self-acting machines of Joseph Whitworth aimed for a precision of 1/10,000 of an inch.  Eighteenth-century England stood out in its ample supply of craftsmen able to do high-precision work. From 1700–1800, England saw a doubling in the number of clockmakers and instrument makers, according to evidence collected by Kelly and Ó Gráda. Besides clocks, these producers made instruments for mathematical disciplines such as surveying, navigation, bookkeeping, and astronomy.

https://worksinprogress.co/issue/how-mathematics-built-the-modern-world/

See also: Exactly: How Precision Engineers Created the Modern World - Simon Winchester