It’s interesting to look back at how life changes over the years. Before this year, my last post on this blog was March 24, 2014. On that day, I posted about how I was distracted by trying to learn the Dvorak keyboard layout. A month and a day after that post, I got married. Since then, I have moved six times (including two new states), switched jobs twice, had a wonderful baby girl, and traveled to a bunch of new countries including New Zealand, Morocco, and Switzerland. Oh yeah, and I learned Dvorak, too.

My Dvorak journey was a bit interesting. I tried to learn it several times before I finally committed to it. I had tried things like typing Dvorak in the morning and then switching to Qwerty in the afternoon, but that didn’t stick. What made it really stick is completely switching over and abandoning Qwerty for my day-to-day typing.

Once I finally did commit to it, it wasn’t long before I was typing faster in Dvorak than in Qwerty. But that wasn’t really a good thing. The reason I was faster in Dvorak was because I could no longer type quickly in Qwerty – Dvorak had completely messed up my Qwerty skills. Before I committed to switching to Dvorak, I averaged 92 WPM with Qwerty (according to https://play.typeracer.com/). Once I reached the 35 WPM mark in Dvorak, though, my Qwerty speeds had decreased to 15-20 WPM. My brain was so confused about how to type – it was an interesting sensation. Fortunately, over time my Dvorak speeds increased, but even a couple of years later, I’m still not to the speed I had been with Qwerty. I average 87 WPM now with Dvorak and I can usually type about 30 WPM in Qwerty.

I actually didn’t learn traditional Dvorak. The variant of the Dvorak that I learned is called Programmer Dvorak. There are two other peculiarities about that layout that make it even more challenging. First of all, the numbers are arranged in a different order – 7,5,3,1,9,0,2,4,6,8 – instead of 1,2,3,4,5,6,7,8,9,0. I’m not sure why they did that, but it works fine once you learn it. And the other peculiarity is actually what makes Programmer Dvorak so great, in my opinion. All of the symbols that you would normally have to press shift for are unshifted – instead, the numbers are shifted. That means that in order to type a 4 I have to press shift plus another key. But to type =[{}] I don’t have to press shift at all. This is generally pretty great for programming. I type (), =, and [] all the time. And I rarely type numbers. But it does make dealing with spreadsheets and financial data worse in some ways. However, I can always press caps lock and get unshifted numbers back.

After I had been typing with Dvorak for some time, I purchased an Ergodox EZ. It is a pretty amazing keyboard – it’s completely customizable and uses a concept called “layers” that allow you to use the same key for a dozen different things depending on what layer you are using. It was very intimidating to set up and get used to, however. It probably took me a week to figure out a layout that I liked and another week to get used to it. But since then I’ve customized my layout to a point that I really enjoy: https://configure.ergodox-ez.com/ergodox-ez/layouts/o99MZ/latest/0. By Ergodox EZ standards, I think it’s pretty simple. One thing of note is that I put escape where caps lock would normally be (since I’m a huge vim keybindings fan). However, unlike most people who do this, I actually like using caps lock in certain situations, so I also have caps lock easily within reach. After getting used to this layout, I’ve been able to use the mouse less and stick with the keyboard more. And I really enjoy typing with my hands spaced further apart.

It has been fun looking back on some memories of things that have changed in the last few years and things that have stayed the same.

My ham radio license was issued this week! I have a technician class license, and my callsign is KJ7SIL.

Now I need to figure out how to actually make a successful transmission. I have a two-meter handheld radio that I can receive a couple of the local repeaters, but I haven’t been able to key one of them up. Which either means that I have something misconfigured with my radio or it just doesn’t have enough power to reach the repeaters. Hopefully my dad – who is a very experienced ham – will be able to help me figure it out when he comes to visit.

I very highly recommend the book Seeking Allah, Finding Jesus by Nabeel Qureshi.

This book has increased my respect for Islam. I am impressed by the discipline Muslims have. For example, every day they pray three times. And not just in private either – they are very open about it. It can even be a social thing. I wish rituals like this were more common in Christianity to encourage a more consistent prayer life.

This book also increased my faith in Christ. By watching Qureshi go through his journey from devout Muslim to Christian, I really got a sense of how attractively and convincingly Christianity can be presented. Of course, I am quite biased when it comes to being convinced of Christianity, since I myself am a Christian. I think that my bias probably makes Qureshi’s story more satisfying.

It may be helpful to put myself in the shoes of someone who does not believe in Christ who might read this book. As an example, I doubt there would be much in this book that would convince an atheist of the existence let alone the power of Christ to change lives. Qureshi clearly believed in God from the outset. At no point did he even question the existence of God. He simply questioned whether the God he had been worshiping was the god of Muhammad or whether he was the father of Jesus Christ.

There is one part of the book that I think would be especially unconvincing for someone who questions the existence of the Christian Father God. Qureshi was struggling with some horrible acts of Muhammad that he had learned about – for example, that Muhammad ordered his men to rape women. The obvious issue with Qureshi’s struggle is that the Old Testament states that God called for behavior from the Israelites that was every bit as violent and disturbing.

In another book I’ve been reading – Saying No to God by Matthew Korpman – Korpman expresses his distress that many Christians try to defend some of the things that God seems to condone in the Old Testament. He brings up the example of Numbers 31 where God commands Moses to “Take full vengeance for the sons of Israel on the Midianites; afterward you will be gathered to your people.” This leads to Moses and the Israelites slaughtering the Midianites – even women and children – and sparing only the virgins. In fact, the Israelites even spared the women and children before Moses commanded them to “kill every male among the little ones, and kill every woman who has known man intimately.” There are a number of different views of texts like these. Korpman’s view is that God didn’t actually want people slaughtered or virgins forcefully taken as wives. I’m not sure if that’s the right answer or not, but texts like these certainly place the God of the Old Testament in a similar light to the Muhammad that Qureshi ultimately rejected as a prophet. I would like to know how Qureshi resolved issues like this in his own mind.

All that to say, it was difficult for me to relate to Qureshi’s struggle with Muhammad’s violence when there are many Christians who have left the faith due to accounts of God’s violence. I think violence is something that needs to be addressed when considering either of these Abrahamic religions. Unfortunately, that’s a much bigger topic than I’d like to get into in this blog post.

I believe I’ve established that this book probably wouldn’t be effective at converting someone who didn’t already believe in a deity of some description. I think it’s telling, though, that Qureshi makes it fairly clear how you could convert someone – through friendship. Qureshi’s friendship with David Wood lead to him being converted. Wood also met an atheist girl and was instrumental in her conversion. So I see that it’s through relationship with people that conversion happens. If Wood hadn’t become very close friends with Qureshi, there is no way that Qureshi would have listened to anything that Wood had to say.

It is the description of friendship between Qureshi and David Wood in this book that really had an impact on me. It is profound what an effect we can have on other people if we truly care about them. That was my main takeaway from the book – befriend those around me. Show my care for them and live my life in a way that honors God. That is the most effective way I can witness. I definitely recommend that you read this book.

I have finally finished reading Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer after many months. Now that I’ve made it through the book, I would subtitle it “The Hipster’s Waterfall.”

To be fair, it is a thought-provoking book. It has some good ideas for new techniques in managing software projects. It is well written and clear, and I think Singer does a decent job of arguing for the processes and techniques he recommends. I just don’t agree with some of his more foundational points and therefore I do not agree with the general thesis of the book.

More on my disagreements later; first, I’d like to point out the pieces from the book that I think are sound.

I think that the general concept of shaping work before working on it is excellent. The high-level idea is that you would make some rough designs and sketch out the flow and functionality of the work you’re about to do. This helps flush out any major issues with the design before getting into the details. The three properties of shaped work that I agree with are:

1. It’s rough: the initial design should be at a high level.
2. It’s solved: the solution to the problem has been well thought out. Open questions and rabbit holes have been resolved.
3. It’s bounded: the scope – and what is out of scope – is clearly defined.

I find doing this type of design beneficial. It helps point out serious flaws with initial ideas.

Along with the general idea of shaping, Singer presents some ideas for creating rough designs – breadboarding and fat marker sketches. Breadboarding (named after the breadboard used for prototyping electronic circuits) is a way of sketching out a flow – basically a more informal version of a flow chart. Fat marker sketches are rough sketches of a user interface design. They are meant to show all of the critical parts without dictating the final design. Both of these ideas seem useful, though perhaps not very original.

The one thing in this book that I think is original and could be useful in practice is the hill chart.

A hill chart is a convex curve that is used to communicate progress on a work item. As you are making progress on the item you’re working on, you move a dot representing the item from left to right on the hill chart. If you are still figuring out the unknowns, approach, and design of the item you’re working on, then you would place a dot on the uphill part of the hill chart. If you’ve figured things out and are simply carrying out the plan to finish the item, then you would move the dot to the right on the downhill part of the hill chart.

Now that we’ve covered the pieces in the book that I do agree with, I’d like to move on to the fundamental issue I have with the book. I would very much dislike being a developer or a designer at Basecamp. In the section Who shapes, Singer paints a very clear picture of empowered shapers and indentured delivery teams. What I mean by delivery team is a team that simply takes tasks as input and produces software as output. They are not responsible for solving business problems. They are only responsible for producting code that meets some requirements.

Marty Cagan’s writing has influenced me greatly, and I have learned that my desire is for empowered product teams. The empowered product teams that Cagan describes seem to be the direct opposite of the teams that Singer describes in this book. Basecamp doesn’t have a cohesive team that collaborates amongst themselves and with customers to reach a solution to a business problem. Basecamp has a team that decides on which business problem to solve, designs a solution that is meant to solve the problem, and then hands it off to other people to implement. I am not a fan.

In his articles, Cagan points out that there are four risks associated with creating or improving a product: – Value risk (will people buy it, or choose to use it?) – Usability risk (can users figure out how to use it?) – Feasibility risk (can we build it with the time, skills, and technology we have?) – Business Viability risk (will this solution work for the various dimensions of our business?)

With an empowered product team, the team is responsible for all of these risks. The team’s Product Manager is responsible for value and business viability. The Designer is responsible for usability. The Technical Lead is responsible for feasibility. This works well because each responsibility is owned by someone on the team who can either communicate directly with the people doing the implementation or perform the implementation themself.

In the process that Basecamp uses, all of these responsibilities partially or wholly lie with the shapers, and the actual implementation of the solution is handed off to another team – a delivery team. I think a good term for this type of process is insourcing. The shapers identify a problem their customers have, design a solution to the problem, and decide whether it’s usable, feasible, and a fit with the business. Then they hand the work off to their insourced design and development teams to implement the solution.

Another issue that I have with this book is its recommendation of six week cycles. Singer claims, “six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.”

Maybe they don’t have any procrastinators at Basecamp, but I think most would agree that a six week deadline doesn’t loom very large. Anyway, I think Singer is missing the point of why you would want a shorter iteration. A shorter iteration provides more frequent opportunities to interact with the customer and course correct.

The other benefit of shorter iterations is smaller batches of work. There is power in small batches

There is a name for a process that features up-front design which is handed off for development and long feature development cycles. The name for this process is waterfall. Basecamp uses waterfall with some minor adjustments to make it more palatable.

The interesting thing is that Basecamp is clearly making waterfall work for them. There is no denying they have a successful company, so no one is really in a place to criticize their approach. I personally wouldn’t enjoy working there, but when you have bootstrapped your company and are profitable you have a lot of flexibility to run things the way you want. And therein lies the true success of Basecamp.

So, in summary, I wouldn’t recommend the overall process that Singer recommends in Shape Up, but there were still some tidbits of wisdom within. I don’t recommend reading this one.

I did not enjoy Prey as much as I thought I would. I think there are a couple of things that I struggled with while reading it.

The first thing I struggled with was actually a problem with the type of topics that Michael Crichton likes to take on. I think of his writing as near-term science fiction. It’s definitely science fiction, but it isn’t far-fetched science fiction that takes place centuries in the future. It’s the type of science fiction that I could imagine happening tomorrow. Usually, I appreciate that, since it explores ways that the world could be different today. However, it can also backfire.

One way that near-term science fiction can fall short is in longevity. If the author is making predictions about how present day technology will evolve then people don’t have to wait very long to see whether the other was right. And if the author wasn’t right about the evolution then readers may soon lose interest.

I think that missing the mark on predictions of the evolution of technology is where Prey falls short. Without giving too much away, one of the premises of the book is that large swarms of nanobots can evolve to the point where they can have a sort of intelligence and learn new things – with very minimal programming.

I think at this point the development of artificial intelligence and machine learning has shown that this isn’t really possible. The algorithms for machine learning that computer scientists have developed to this point show some promise, but not the level of learning the Crichton portrays in Prey. And especially not with swarms of low-resourced agents.

Prey was a mildy interesting book, but I don’t think I would recommend that anyone read it. It wasn’t terrible, but it certainly wasn’t great.

I have been very busy, but that’s no excuse. I’m lowering the bar for things that deserve a blog post. This particular post will feature things I’ve been thinking about and doing.

Things that have happened

My sister and her kids came to visit a couple of weeks ago. It was a fun visit! Everything was made more complicated by COVID, but it all turned out OK.

I crashed my mountain bike on Sunday, which was not fun. It was one of the higher speed crashes I’ve had. My front tire washed out on a corner and I slid quite a ways, scraping up my knee (even though I was wearing knee pads) and somehow hurting my pinky, which has been the most debilitating result of the crash.

I received a promotion at work. I am now leading the Infrastructure squad at Seeq. This is exciting for me, since I enjoy working on cloud-based infrastructure and development tools, which is what the team is responsible for.

Books I’ve been reading

I finished Prey by Michael Crichton. I plan to write up a book review of it soon.

I also finished reading Being Mortal, which was a superb book. I’ll have to refer to it again the next time I’m faced with the mortality of myself or someone I love. I should also write up a review of that book.

I have been working on another excellent book, which I hope to finish soon, Seeking Allah, Finding Jesus by Nabeel Qureshi. I’ll post more thoughts when I’ve finished it.

Projects I’ve been working on

I have been plugging away at editing a YouTube video of a morning ride I did in Reno. It’s been so long since I’ve edited any video that it’s proving a bit time consuming. I hope to have it finished and posted soon.

Tralina and I have also been getting more serious about cooking. Tralina purchased a Shun santoku knife, which is very nice. I will be getting a chef’s knife soon. I have been browsing Forks Over Knives quite excitedly, looking for recipes that look good. Today I cooked Mediterranean Vegetable Spaghetti, which was not very good and definitely did not meet Tralina’s approval. I also made a “No-Tuna” Salad, which Tralina did approve. She said that it reminded her of the tuna salad that her mom used to make before I even mentioned that it was supposed to be a tuna salad substitute. So I call that a win!

What’s next

It might be nice to post regular updates similar to what Sacha Chua does on her excellent blog. If I decide to do that, I’ll probably want to come up with a consistent format.

I’ve been listening to the book Being Mortal by Atul Gawande. I’m a few chapters in, but I’m already finding the book very informative and thought provoking.

Gawande paints a compelling picture of what it means to grow old in our society and how old age has changed in recent history. Living over the age of 70 used to be a fairly uncommon achievement, but with modern medical advancements, it is almost commonplace. That fact has many implications for how the elderly are treated, and how they want to live in their twilight years.

The point that I have resonated with the most is that at some point, no matter how I take care of myself, my mind and body will start to break down. I will not be able to think as quickly as I can now. I will not be able to remember quite so well. My heart won’t pump blood as efficiently. My bones will become brittle. My muscles will shrink away. As Philip Roth put it, “Old age isn’t a battle: old age is a massacre.”

And there is nothing I can do to stop the decay. I can only put it off through healthy living. So I will seek a healthy life.

But in the meantime, while my mind is still sharp, I have things that I want to accomplish in my career. I want to start a business of my own. I want to make a big impact in every place I’m employed. I want to be influential in my field.

In the meantime, while my muscles are still strong, I have things I want to accomplish as a father. I want to play sports with my daughter. I want to teach her how to ride a mountain bike. I want to take her on a backpacking trip. I want to hug her and swing her around when she visits home after going away to college.

In the meantime, while my heart still beats with passion, I have things I want to accomplish as a husband. I want to take my wife on exotic trips. I want to provide a comfortable house for her to live in and a beautiful yard and garden for her to enjoy. I want to dream with her and partner with her to fulfill those dreams.

In the meantime, while my soul still burns with devotion, I have things I want to accomplish as a child of God. I want to introduce someone to Christ. I want to nurture another small group. I want to share my testimony with someone who needs to hear that others have been there, too.

And then, when old age sets in and my mind dulls, my muscles atrophy, my heart slows, and my soul flickers, I will look back on how I did not waste the strength, energy, and mental acuity of my younger days. I will reflect fondly with my wife on a life well lived. And I will anticipate eagerly meeting my Savior face to face.

Skunk Works by Ben Rich is a memoir about Rich’s time working at the Lockheed Skunk Works. The Skunk Works is a small, secretive, advanced research and development organization within Lockheed. Rich relates his experiences from first being tapped by Kelly Johnson – the founder of Skunk Works – to design some systems on the U-2 spy plane to taking the reins when Johnson retired to his own eventual retirement.

The philosophy of the Skunk Works is what stood out to me in the book. Skunk Works isn’t just a secret department within Lockheed. The Skunk Works philosophy emphasizes small, flat, tightly integrated teams that have autonomy to make decisions about their projects. Kelly Johnson’s 14 rules and practices provides a map for the Skunk Works to operate. Engineers are required to visit the shop floor to interact with those machining the parts and assembling the aircrafts. Outside inspections are kept to a minimum. Unnecessary documentation must be eliminated, but important work must be comprehensively reported.

It is difficult to argue with the results of the Skunk Works’ approach. Guided by Johnson’s 14 rules and practices, the Skunk Works was able to develop aircraft that were in some cases decades ahead of anything their competitors could design or build. The U-2 spy plane set elevation records that made it untouchable by enemy aircraft or missiles. The SR-71 blackbird still holds the airspeed record for a manned airbreathing jet engine aircraft… which was set 44 years ago in 1976. The F-117 Nighthawk was the very first stealth aircraft – designed not to reflect enemy radar. Only one Nighthawk was ever lost in combat. And they often created these airplanes and others ahead of schedule and under budget.

Ben Rich personally worked on every one of the aforementioned aircraft, so Skunk Works includes many fascinating anecdotes about the technology, politics, missteps, and successes that went into each one. Rich also relates accounts of other Skunk Works projects – some successful, some not – as well as personal accounts of his relationship with Kelly Johnson and other aspects of his life.

Some particularly interesting sections of the book are anecdotes provided by people other than Rich. I enjoyed hearing from test pilots, politicians, military brass, and Rich’s coworkers. Some of these accounts really helped emphasize the impact that Rich and the Skunk Works have had over the past seven decades.

I think that there is a lot to be learned from the Skunk Works approach to work. It’s possible to accomplish a great deal with small, efficient, autonomous teams. I was inspired by this book to pursue a similar approach in my own work, and I was spellbound at points that such great feats of engineering could be accomplished with so little.

As I’ve mentioned before, I’m rebuilding this website using Clojure.

When starting a new project, I find you often have two choices: start with a batteries-included framework or build up the framework yourself from your own code and any libraries you might want to leverage. I usually choose the first when I want to get something up and running quickly. I choose the second when I want to learn as much as I can and have fun tinkering along the way.

This time, I am choosing to build up the framework of my application myself. In the past I have used a baterries-included web application template, chestnut, but this time I decided not to go that route. One reason I decided not to use chestnut is that I don’t think I’ll need any client-side cljs code. Chestnut’s main use case is compiling and reloading cljs.

The only functionality I want in the first iteration of my framework is markdown to HTML parsing, an HTTP server to serve that HTML, and live reloading (reloading of the page when something server-side changes).

To support those features, I have started evaluating the libraries I want to use:

• These are micro-frameworks for managing dependencies, keeping things loosely coupled, and setting up a reloaded workflow for development. Integrant is currently the frontrunner.
  • Integrant
  • Mount
  • Component – I’ve used Component once before, but Integrant claims to solve some of the difficulties I had with Component.
• Ring – the de facto standard Clojure web application library.
• I have decided to use bidi as a routing library because I don’t like Compojure.
  • bidi – a routing library that just uses data structures for defining routes.
  • compojure – a routing library which I find distasteful due to its unnecessary use of macros.
• hawk for watching files to kick off live reloading.

I would like to keep the libraries I’m using fairly minimal. I may add some more to this list for things like generating HTML, but I’d like to write a quite a bit of code myself.

I feel good about choosing to build up the framework of my application myself. Getting to know each piece may help me develop the application even more quickly in the long run.

I have been reading Saying No to God by Matthew Korpman. The general thesis of the book seems to be that God invites us to stand up to Him and argue with Him as part of our relationship with Him. I think I generally agree with that viewpoint. However, I’m not yet half way through the book, and after the second chapter I almost stopped reading because of one assertion.

The assertion in question is in the chapter titled “Abraham Didn’t Believe God.” In this chapter, Korpman tries to convince the reader that Abraham never believed that God wanted him to kill Isaac. I find numerous problems with Korpman’s arguments throughout the chapter, but I will focus on this single point, since I absolutely cannot accept it. While discussing Abraham’s unfulfilled sacrifice of Isaac, Korpman states,

Many have long attempted to suggest that Abraham trusts that God has the ability to resurrect Isaac back from the dead after he kills him. Ignoring how gruesome that idea is at face value, the historical reality is that this is simply not possible. The idea of resurrection, historians are aware, did not exist for either Abraham or the Israelite authors of Genesis. It was an idea that first appears in the prophet Daniel and only became popular at the time of Jesus. Entire books exist to demonstrate why we know this with absolute precision. As such, scholars can confidently rest assured that whatever Abraham is doing when he suggests that he and Isaac are returning, it isn’t due to resurrection.

I have a couple of big problems with this statement. First of all, it’s simply ridiculous to assert that the idea of resurrection did not exist for Abraham. There is no way that you could prove that from scholarship… Second and more importantly, Paul, in his inspired letter to the Hebrews states,

By faith Abraham, when he was tested, offered up Isaac, and he who had received the promises was offering up his only begotten son; it was he to whom it was said, “In Isaac your descendants shall be called.” He considered that God is able to raise people even from the dead, from which he also received him back as a type. Hebrews 11:17-19

So indeed, “many have long attempted to suggest that Abraham trusts that God has the ability to ressurect Isaac.” In fact, Paul attempted to suggest that. And I believe Paul over the entire books that exist which would suggest otherwise. This argument of Korpman’s makes me wonder if he discounts this statement of Paul’s because of advances in scholarship or if he just wasn’t aware that the argument originally comes from Paul. After reading a good chunk of the book, I think it must be the latter. If he was aware this argument for resurrection came from Hebrews, I think he would have at least mentioned it and felt he needed to justify his statement against it. Therefore, the rest of Korpman’s book loses significant credibility for me.

It’s fairly clear to me that Abraham did believe God. Most of all, he believed God’s promise that “in Isaac your descendants shall be called.” He believed that no matter what God had him do, God would fulfill that promise.