Inequality and Risk

I’ve been slowly making my way through Paul Graham’s essays, and for the most part, I’ve been enjoying the journey. Recently, I came across his essay, “Inequality and Risk,” and it gave me a few thoughts. As Paul said: “The word ‘essay’ comes from the French verb essayer, which means ‘to try’”, so let me try.

“Like many startup founders, I did it to get rich. But not because I wanted to buy expensive things. What I wanted was security. I wanted to make enough money that I didn’t have to worry about money. If I’d been forbidden to make enough from a startup to do this, I would have sought security by some other means: for example, by going to work for a big, stable organization from which it would be hard to get fired. Instead of busting my ass in a startup, I would have tried to get a nice, low-stress job at a big research lab, or tenure at a university.

That’s what everyone does in societies where risk isn’t rewarded. If you can’t ensure your own security, the next best thing is to make a nest for yourself in some large organization where your status depends mostly on seniority.”

Paul Graham

I understand that startups are incredibly risky—it’s a fact. People investing in startups also take the same risk as founders, or perhaps even more. So if the reward isn’t worth it, then investment—and therefore startups—won’t be worth it, which means development stagnates. I agree with this argument.

But here’s my question: does progress and development only happen with big rewards? Paul says it isn’t about the money but about security. There are different ways to achieve security: one way is to make lots of money, and another is to get a secure job—a low-risk, low-stress position that’s stable and reliable. So if there’s no risk and no reward, does that mean all brilliant minds would gravitate toward secure jobs in big companies, research institutions, or government?

What about Albert Einstein? He made it. Now, for the sake of argument, what if security were already provided? Let’s wave a magic wand and imagine you receive enough money to live well. Wouldn’t you then want to dedicate yourself to what you do best—perhaps to development and innovation? Maybe one could be driven purely by a desire to innovate, rather than by the promise of big rewards or security. Not everyone becomes a doctor just to make loads of money. Some people genuinely want to help others and improve lives. Shouldn’t pure curiosity and the desire to improve be enough motivation?

I get it—there’s no magic wand. There’s resource competition. Effectively, this is all about security and resources: if you don’t secure yours, someone else will. It’s funny (and sobering) how quickly the argument can devolve back to a Stone Age-level mentality—it’s either you or them. But that seems to be what Paul is describing in his essay. We need inequality and risk to drive development and stay ahead, which in turn allows us to secure and gain more resources.

I’m not saying Paul is wrong, and I don’t claim to have better ideas. I’m just pointing out these dynamics and wondering out loud if there’s a better way. Ultimately, it might be the only way—our technology, biology, and language may simply be inadequate for any other existence.

The word “essay”

The word “essay” comes from the French verb “essayer”, which means “to try”. An essay, in the original sense, is something you write to try to figure something out. This happens in software too. I think some of the best programs were essays, in the sense that the authors didn’t know when they started exactly what they were trying to write.

Paul Graham

The Chronicles of the Fallers

The last time I picked up a Peter F. Hamilton book was about a year ago. Unfortunately, Misspent Youth wasn’t very impressive compared to the rest of the Commonwealth Universe. However, it gave me a goal: to finish all the books in the Commonwealth Universe. Jumping ahead, I must say: I love the Commonwealth Universe. It might start slow with Misspent Youth, but it picks up steam quickly in the following books and doesn’t stop until the very end.

The final series, The Chronicles of the Fallers, consists of two books: The Abyss Beyond Dreams and Night Without Stars. The story takes place both within the Void and outside it, recounting the tale of humans trapped with a highly hostile alien race and their desperate struggle to survive. The author masterfully weaves an intriguing story about a society that once thrived on advanced technology but is forced back to 21st-century tech levels as it attempts to return to the Commonwealth—all while fending off the Fallers.

The series brings back two main characters: Nigel Sheldon and Paula Myo, who both work to rescue humans from the Void and the Fallers. Hamilton expands on the inner workings of the Void, giving the story an exciting twist while managing to keep the Void series on its own unique path. Additionally, he delves into how the Void’s mechanics became so convoluted and expansive by the end of the Void series.

I enjoyed The Chronicles of the Fallers immensely. It connects beautifully with the previous books while developing a new, exciting storyline. The entire Commonwealth Universe is a sublime experience, and I wish Peter would continue working on it, but otherwise, it is a great place to stop.

I know I haven’t discussed much of the plot, but I feel I wouldn’t do it justice. The Chronicles of the Fallers must be read as a sequel to the earlier stories. That way, you’ll be fully immersed in the experience. If you enjoyed the previous books, you won’t be disappointed—I certainly wasn’t.

In a nutshell:
+: Well-written and easy to read
+: Continuation of the Commonwealth Universe
+: Old characters in a new setting
+: New and exciting storyline
+: A wonderful finale to the entire universe
=: Excellent books, but I highly recommend reading them only after finishing the previous series

Title: The Chronicles of the Fallers
Author: Peter Hamilton
Cover:

The Software Architect Elevator

I never read books about architecture or architects, and reading this book wasn’t my idea. However, once I commit to something, I see it through. I purchased the book a few months ago, new, for about $66 (Canadian dollars). I’ll come back to the price later. The book itself is relatively small and short, a bit over 300 pages with a well-sized font, ample space between chapters, and the smallest page area I’ve ever seen in a technical book.

I’ve never held an architectural position, and in fact, I have a fairly limited understanding of an architect’s role in the first place. With over a decade as a software engineer, I tend to see architects as people to avoid whenever possible, as they often say “no” to technical or design proposals more than “yes.” Granted, software engineers can be overly eager to make unnecessary changes or introduce new shiny tech that ends up causing more problems or becoming redundant. But to this day, I only approach an architect when all other options are exhausted and never with new ideas or proposals.

“It is often easier to ask for forgiveness than to ask for permission.”

Grace Hopper

Given all of the above, expressing an opinion on this book is challenging, as I have nothing to compare it to. However, I’ll share my thoughts and feelings about it

The Good: The book is easy to read and understand. The author does not waste time stretching out discussions unnecessarily. The list of topics is solid and covers many critical areas of any IT organization. I found a few nuggets that resonated with me, such as automation, standardization, version control, diagrams, and feedback. While I have minor disagreements on automation, I generally align with the author and hope modern IT organizations follow these ideas and recommendations. The book also includes plenty of references to other materials, books and movies.

Ugly bits: While the references to other resources are appreciated, there is an underlying irony: if you’ve read some of the books mentioned, you likely don’t need to read this one at all. Kent Beck, Robert C. Martin and Martin Fowler, for example, provide enough practical knowledge, discussions, and examples that render many subjects covered here self-evident and redundant. Furthermore, while the book covers a broad range of topics, it often lacks depth and detail. It feels like reading an abstract with a bit more substance; the subjects are clear and touched upon, but there’s little practical detail to learn from. It feels like a lot of knowledge but practically little comes to fruition.

The Bad: The author frequently explains concepts through analogies, drawing from non-tech areas. While analogies can be effective, some of these were poorly chosen. Occasionally, the analogies were overly simplistic; at other times, they were unnecessarily complex. In rare cases, the analogy was worse than the technical explanation itself. For instance, the author used forensic/police sketch artists as an analogy for architectural mapping/diagrams. This was frustrating—it felt irrelevant, and I have no interest in, nor do I understand, police work. Another annoyance was the inclusion of URLs for diagrams in a printed book. Why not print them? The chapter on diagrams seemed interesting but ultimately uninspired, as if the authors added just enough content to make it feel important but not enough to fully explore the topic or provide more examples. I found it perplexing that the book relied so heavily on unrelated analogies, considering it isn’t targeted at novices. Surely, any software engineer or architect reading this book would have a baseline understanding of IT. The author could have used this space to provide more detailed discussions and practical examples instead. Lastly, the book’s treatment of hiring and staffing was minimal. While it mentions the importance of interactions across organizational levels, it barely touches on better hiring practices and only in passing. It’s ironic that the author can talk about communicating between the “engine room” and the “penthouse” but neglects to elaborate on Human Resources.

So, what’s the verdict? Let’s go back to the $66 price tag. For that amount, I expected at least 400 full-sized pages of deeper, more practical knowledge. I’m not sure who this book is for. Is it for the ivory tower architect who lost touch with tech a decade or two ago? Or for the new architect who has only heard of Git, pipelines, and containerization in passing at a conference? The book isn’t bad, but I can’t say it’s good either. Would I buy it again? No. Would I recommend it? No. You could gather the same knowledge by locking yourself in a room with YouTube for 10-20 hours and watching IT conference talks by top industry architects. I would give the book a green light for $20, as it is short and has a few valuable nuggets, but not for $66.

In a nutshell:
+: Easy, fast, and short read
+: Covers various relevant IT topics
+/-: Includes many references and broad topic coverage
-: Heavy reliance on analogies, not all effective
-: Lacks depth, details, and practical discussion
=: Don’t waste your money. If you can pick up the book for $20 and are interested in the topic, go for it. Otherwise, spend time on YouTube learning from top industry architects for 10-20 hours, and you’ll likely be better off.

Title: The Software Architect Elevator: Redefining the Architect’s Role in the Digital Enterprise
Author: Gregor Hohpe
Cover:

The-Software-Architect-Elevator-NotesDownload

Assembly: An Outdated Course in CS

Recently, I had the chance to peek at a university computer science program (at my local university), and I was a bit surprised — not much has changed since my time, which made me feel a bit sad and wonder. You see, I work with young graduates, and essentially, they need to be taught everything. They don’t even know half of the stuff a developer needs to know in order to get or do the job. Mind you, I work for a company that is pretty far from the technological bleeding edge. And even then, most students entering the workforce don’t have enough skills and knowledge for the job, so they have to learn on the job.

There is nothing wrong with learning on the job, however, I do wonder: why do young people pay tens of thousands of dollars only to be taught outdated subjects, skills, and practices? The traditional answer from any CS university department would be, “We are teaching science here…,” but that’s not entirely true. Many of the courses are not focused on science; they are focused on software development. Those courses will teach you how to sort an array in five different languages — that doesn’t seem very scientific to me. Ironically, these are the courses that will get you a job or at least give you the chance to learn on the job, because without that knowledge, no one would even take a chance on you.

Let me pick one course that really grinds my gears: assembly. This particular course is horrifically outdated. Twenty years ago, when I was studying at university, the assembly course was already old and riddled with generations of mistakes that the professor refused to correct. Now, 20 years later, the same nonsense has only gotten worse.

First, the course is taught only in Microsoft Macro Assembly (MASM). So you must get Windows and install gigabytes of software, libraries, and other stuff just to run a simple, one-page assembly code that wouldn’t even add up to a kilobyte once compiled. If you are running Mac or Linux, well, you’re out of luck. The course guide recommends you use virtualization to run Windows and install all the necessary software. The course suggests a couple of alternatives, such as using NASM, which will not be supported or explained by the teacher, or using a Docker container, which is created by students, untested, and once again not supported by the teacher. Remember, you’re paying for this! Isn’t it marvelous?

Why can’t the software be organized in a simple VirtualBox image or, better yet, a Docker container that contains all the instructions, examples, and runs on any OS? Is a student taking this course supposed to learn how to install Windows and set up Visual Studio with all the dependencies? It took me nearly five hours to get everything installed and configured, and I’m no stranger to this. Let me say, teaching students how to install and use virtualization is far more useful and important than teaching them how to install Windows and Visual Studio.

Second, why do computer science students need assembly? Let me be blunt: I learned it, passed the course, and forgot it, never to remember it again. I don’t think an assembly course is needed for a general-purpose computer science degree. There’s no use case. The industry is working towards replacing the C language, and no one even considers assembly for any meaningful work. Yes, there are cases where people are still using assembly, such as Steve Gibson. Perhaps CS students with a cybersecurity focus must know/understand assembly, or perhaps video game developers might find assembly knowledge useful, but for most, learning assembly is a waste of time.

Instead of an assembly course, perhaps students should be taught to use VCS like Git. Git is useful, and its design is fascinating from a CS point of view (graph theory and such). Another useful topic would be build systems, such as Maven. It’s hard to imagine a company that doesn’t use a build system for continuous integration and delivery. Unit testing is another good subject that is both useful and applicable to any language. Process automation is yet another important subject. From a programming perspective, software design, functional programming, and refactoring are much more valuable knowledge than assembly language. In fact, all of these topics could be combined into a highly useful course instead of learning a useless assembly language.

Ironically, computer science programs keep teaching the same old and sometimes flawed material without any regard for the current state of the computer industry. It’s quite interesting to observe that only the professors who have worked in the industry understand this and organize their courses differently — I’ve seen it! But they’re 1 in 10. The rest teach outdated material from papers written 30+ years ago…

The Last Journey

Immortality is not an option, so we must face the music sooner or later. On a grand scale, the life of a person is not very noticeable; thousands of people embark on their last journey every day. Yet, those closest to us feel particularly special. I’ve been told that everyone processes such an event in their own way, and I’m no different.

For some, the journey starts abruptly, while for others, the beginning stretches out, like trailers in a movie theater before the main show. The prolonged ones seem to be the most difficult. Horrible pain and suffering, without even a glimpse of hope. Can you imagine being sick—having an endless flu, a fever that never breaks, constant headaches, muscle pain, coughing, and a runny nose? And along with all of this, you know, you understand, there is no getting better. There is no recovery. This will end in only one way. Now, multiply that pain several times over.

Departures are always sad. We miss loved ones, even when they embark on a great journey, yet these departures aren’t typically accompanied by excruciating pain that lasts for months on end. After all the pain, suffering, and goodbyes, the journey begins. So shouldn’t we rejoice that our loved one has finally embarked? Shouldn’t we feel some happiness, at least for their sake? Not for our own selfish feeling of being left behind, but joy for their journey—for their release, for the end of their suffering, when nothing more could be done. I don’t know the right answer. I just feel serene, with a trickle of sadness and joy. In my mind, it is not about me; it is about them, wherever they are now.

Rest now, Aunt Zoya.

Mazda MX-5 Miata NC soft top roof does not pop up

Forum: https://forum.miata.net/vb/showthread.php?t=412894
Parts:
– https://shop.advanceautoparts.com/p/dorman-help-bypass-caps-5-8-in.-i.d.-02252/5014182-P
– https://www.amazon.ca/Dorman-02251-EPDM-Coolant-Bypass/dp/B00Z7MWUMC
– https://www.rockauto.com/en/tools/cooling+system,radiator,bypass+cap,1000815

BackupDownload

MATG 28

Miata At The Gap is the largest and longest-running gathering of Miata enthusiasts in the USA, and I finally went there. I bought my Miata (or MX-5) back in 2020 and had been contemplating going to MATG for a while. The main challenge was the drive to North Carolina, which is roughly 11-12 hours from Detroit. However, this year, due to family circumstances, I finally realized: I wanted to go and therefore I must go. None of us are getting any younger, so there is no better time than now.


I wasn’t entirely sure what I was doing, and as it turns out – it was just fine! I booked a cabin in Nantahala Village since it had one small but crucial advantage – a pool. The pool was important since I was bringing my kid along, and she loves to swim. Also, I wasn’t sure how she would handle the drive, as she gets motion sickness, but it has been improving over the last few years. Looking back, it was absolutely the right call. I didn’t pack much (MATG officially lasts 3 days), but I packed clothes for 6 days (sometimes it gets very hot and humid, so extra clothes), a liter of water, and toiletries. I read a few things about MATG but didn’t dig deep, partly because I didn’t have enough time and partly because it might just be a bit more fun to discover things as I go along.


Let me tell you, MATG was fun. Most of the fun is derived from the location – the mountains are awesome, and driving a Miata there is just a blast. Even better is driving along with other Miatas. The event is awesome; people are nice, easy-going, and just fun to hang out with. There are all kinds of people, from young to old, kids, gramps, ladies, gentlemen, and everything in between. It’s just lovely! While the majority of people are from North Carolina and nearby states, there are people who make the journey from afar. I saw a few Wisconsin plates. It is a strange feeling, even though you don’t know anyone, but you feel like you belong.


Even though I didn’t get to drive as much as I wanted, I saw enough to say that the roads are fairly dangerous. Guard rails are few and far between, mostly placed in areas with an insufficient number of trees. My guess is that trees act as natural safety barriers, which I presume will prevent you from dropping down to the bottom of the mountain but will NOT prevent you from ruining your car and yourself in case you go off the road. Roads are narrow and don’t have much of a shoulder, so there is no room for error. Still, mountain roads are a blast, and most of them are limited to 70-90 km/h. I drove on the Tail of the Dragon twice, on the way in and on the way out, and the road is violent. The speed limit is 50 km/h, and there are good reasons for it. It is not safe, just like the rest, but it has such wild turns – the closest description is like going on a roller coaster ride but in your own car without any safety equipment. Now, the level of danger is proportional to the speed, so go slow, and it is safe. I like driving and have driven enough in my life that I never get motion sickness or any discomfort. Well, I should probably say I never had discomfort while driving before I met the Tail of the Dragon. Granted, I didn’t shy away from driving as fast as I could safely manage, but even then, I got a slightly uncomfortable feeling, not motion sickness but slightly light-headed. In my mind, the Tail of the Dragon definitely deserves its fame.


Miata at the Gap is an awesome event. It is easy-going, friendly, and comfortable for anyone. The location is just perfect for any car enthusiast and even more so for roadsters. If you ever wondered about going there, just go! Tail of the Dragon has a lot of events besides MATG. I hope to come back and drive more.


A couple of things to know:
• Cell connectivity in the mountains is spotty at best; there is no connectivity at Fontana Village, so don’t count on it. However, there is free wifi in shops, so download maps beforehand or stop by a shop and download there (that’s what I did).
• Fill up a full tank of gas before going into the mountains. There are gas stations, but they are far and few between. Also, they might not have premium gas (if you need it). It is safer to fill up before going.
• Mountain roads are public roads, patrolled by police, so drive according to the rules.
• Stores like Walmart are far (about a 1-hour drive from Fontana Village), so if you want to get groceries, plan ahead. Or just have a fun run through the mountain roads.

Critical Mass

Critical Mass is the continuation of the Delta-V storyline. The focus now shifts from the journey home to a rescue operation. To save their crew mates, the team must also save the world. It is gripping and entertaining to follow. What intrigues and bothers me is the notion that the environmental crisis on Earth is inevitable, and the only solution is to consume and build more using resources available only in space. While I understand that this is just a plot, it resonates chillingly with our current state of affairs, which is one of the reasons I appreciate Daniel Suarez’s work.

Just to step aside for a moment, yesterday I was thinking about Daniel’s book “Kill Decision”, which I read about 11 years ago. It’s striking how, less than a decade later, we have “killer drones.” Anyone following the Ukrainian war knows about the thousands of drones, both small and large, flying over the battlefield. Although we have not yet reached the point of swarms and autonomous machine decision-making, we are getting closer.

Returning to Critical Mass, while I enjoyed it, I found the first book (Delta-V) a bit more thrilling, perhaps due to the adventure of going to space. Critical Mass feels more predictable, even though the author has left room for surprises and twists. I also feel there is a lack of technological elaboration, especially concerning cryptocurrency. When reading about non-existent fictional technology, providing details is challenging. However, when the technology already exists, it’s a shame not to delve into it. But this is just my selfish desire. Overall, it is an enjoyable book, though I wonder if I will pick it up again in the future.

In a nutshell:
+: Pleasant read
+: Realistic feel of near-future tech
+: Fair continuation of the previous book
+/: Some technologies could have been explored more
-: Less thrilling than the previous book
=: Critical Mass is a nice book and hard to pass up after diving into Delta-V. However, it is less thrilling, and the tech isn’t elaborated as much as I would like. Overall, a nice read.

Title: Critical Mass
Author: Daniel Suarez
Cover:

Cycles, Life & Death

Everyone is different; all of us mutate slightly in different ways, and we don’t all come out identical—well, at least most humans don’t. This bundle of differences is called humanity. I guess that’s what makes it fun—a randomness factor. For some reason, I’ve never liked cycles. In a way, cycles annoy me. The irony is that over time I started to embrace routine, but not for the sake of it, but rather due to an aging body.

20 years ago, I got a gig at a car parts factory, working the night shift, packing plastic parts and cleaning floors when it was slow. The job sucked; I didn’t like working nights and going to sleep when everyone was out and about. But what bothered me the most was the job itself—the endless repetition of the same steps, over and over again, all night long and the next night and the next. It seemed like an endless cycle of doing exactly the same things over and over again.

Although I enjoy video games, the reason I don’t tend to play a lot (besides not having enough free time) is the repetitive cycle. Yes, different cycles and repetitions with a different combination of red, green, and blue on the screen, yet with sufficiently different cycles to get me bored or annoyed. There are only so many times I can go on a quest to kill 10 boars or whichever virtual animal is demanded by a virtual quest giver. Now I’m not complaining about games; I do enjoy them—I played Diablo repeatedly—I just want to point out my own personal mutation for lack of a better word.

Life itself seems annoying; it is repetitive cycles with a different given at each new start. You are 10, so you need to do this and that. You made it to 20 – education time, 30 – family time, 40 – wealth gathering time, 50 – health…, 60 – retirement… and so on. The illustration is crude but has some merit to it. Does it have to go that way? Well… no. There are different ways life can be played or be played out. Hey, remember: “live fast, die young”? – it is a viable option too. If I had a choice, I would probably go to the other extreme; let’s do the whole life thing for a few hundred years and then decide.

Human time constraints seem to put us into well-defined, optimized, and seemingly inescapable cycles. Each cycle presents its challenges, and there’s never enough time. Ricardo Semler had an interesting idea about working less and spending more time on ourselves early on and not waiting for retirement when the body is broken and tired. His arguments and ideas were very convincing! As much as I would love to implement that, I do not live in theory; bills are due, time is running, and food should be on the table. So cycles continue… meanwhile, we miss moments, and before you know it, people near and dear start to die off.

Those endless cycles of being busy, accomplishing things that seem meaningless now. If only we had more time, more time to make educated choices, more time to figure out priorities, more experience to understand what’s important to ourselves. Perhaps one day we may get more time, but for now, the only thing is to dispense it conservatively.