Stephanie Gredell

Bill Gates Speaks

Awhile ago, I finished reading the book Bill Gates Speaks. Purchase it here.

One day while talking to some people about reading books and such, I became fascinated with how much Bill Gates reads. I watched a video on YouTube about his “Think Week” where he would take off to a cabin to read and think. One day I want to do the same.

Following my own curiosity about Bill Gates, I went to the library to check out books on Bill Gates called Bill Gates Speaks. I found some quotes that I thought were insightful.

“Maintaining focus is a key to success. You should understand your circle of competence, the thing that you’re good at and spend your time and energy there.”

There was this time where someone had said that the key to growing in your career was to “be competent” and the above quote really reminded me of that. Instead of trying to be a jack/jill of all things, sometimes it’s better to specialize yourself in just one thing and become truly familiar with it. I was often told in my career to become a “go to person” on something. It helps build credibility and in an odd way, it builds a habit in people to ask you about things and see you as an expert.

Right now, at the time of writing this, it feels like the tech industry has a huge focus on execution and leaves very little in ways of careful craftsmanship. I understand the motivation. It’s a fast paced industry and if you don’t move fast and get ahead of the market, you’re going to be left in the dust. However, this next quote really struck a chord with me.

“Software is a great combination between artistry and engineering. When you finally get done and get to appreciate what you have, it is like a part of yourself that you’ve put together.”

For me, I get a lot of satisfaction when I’m working on a huge feature and things start coming together and the feature actually works. However, I get greater satisfaction when I have the opportunity to go back and improve on the work I’ve done. I appreciate good craftsmanship and it’s a very satisfying feeling when you get to improve old work and raise it to a higher standard. Unfortunately, these improvement opportunities have become a little more rare in my day to day because of the strong focus on execution and delivery. However, I think it forces me to consider “how can I do it right the first time?”

It puts more thought at the start of a project rather than relying on the idea that we’ll have time later to go back and improve it.

“If you take quality as a given, you are always going to have some uncertainty.”

The opportunity to do something fast and of quality is almost never a good game plan. Quality takes time. Could you build something that is viable? Sure. But quality comes with time, iteration and learning.

The next quote reminds me of something someone a long time ago had said to me. It was something along the lines of “do fewer things better.” Here is what Bill Gates said,

“Because there are not enough hours in a day, it’s tempting to try to do two things at once.”

Aside from multitasking being more error prone, I think it’s rarely a good idea to have constant context switching. In my experience, multi-tasking only really works if you have one active task and one passive task. It’s like driving and listening to an audiobook. It works because most of the time, if I’m driving, I’m going somewhere where I don’t need to pay too much attention to what road to take or the speed limit. It’s muscle memory. It affords me to be able to give my ears to an audiobook and focus on what is being said.

Here’s a few more takeaway quotes I noted down.

“Spending money intelligently is as difficult as earning it. Giving away money in meaningful ways will be my main preoccupation later in my life — assuming I still have a lot to give away.”

“The world of business is moving faster and faster and it’s increasingly global. Using these digital systems to keep everybody in touch and analyea information in a rich way will be critical to the success of business in the future.

“But we can afford to make a few mistakes now. And we can’t afford to not try.”

Service and Message Definitions in GRPC

The slow crawl through GRPC: Up and Running continues. You can purchase it here.

I honestly haven’t made a ton of progress because I’ve read and re-read the same few pages while doing the coding examples. However, I did get through most of chapter 2 which gives a very preliminary introduction to using Protobuf and gRPC. I have one more thing to do to finish it off which is running building and running the app (all done through the coding examples that they give, none done from my own creativity).

One of the things that has thrown me for a loop while reading this is the order that they present information. They went into some Java stuff to build out the client and then they went into setting up Gradle. As a person that barely knows Gradle (like just enough to get by on my day to day work), it would have been more helpful if they presented setting up the Gradle project before showing the code examples. Perhaps it’s just me.

So, what have I learned? A lot. Here are some GRPC specific things. There was a ton that I thought was pretty “common sense” and carried over from my general programming knowledge that I didn’t note here.

  • Service definitions is one of the first things you do and that is set up in the proto files. Once you define the definition and compile the proto files, it generates an interface where then you can define the implementation of each method.
  • A service is a collection of methods that are exposed (and can be executed by the client).
  • Alongside service definitions, you can also define message types. A message is the data structure that is exchanged between client and service. A message type contains fields (similar to an object) and each field is numbered so that the field can be uniquely identified.
  • We can only have 1 input parameter per method and can only return one value (I knew this already but worth knowing that the same holds true in the GRPC world). If we need to pass multiple values, we need to define a message type and group all the values.
  • You can import from another proto file if you need to use message types defined elsewhere.
  • You can manually compile the proto file(s) using the protocol buffer compiler or leverage something like Gradle that has a Protobuf plugin that can do it when you run the build step.

This is as far as I’ve really digested. I’ll cover the rest of chapter 2 once I’ve really digested it and executed the code. However, I’ve been trying to move slower through this book so I can really absorb what it has to offer.

The side challenge of all this is deciding on the the tools I want to invest in. At my job, the tools to use are given. There are certain tools supported by the company that will facilitate getting the job done. However, for my own personal stuff, I always struggle between going to what is familiar vs something different. Going with the familiar means purchasing the same tools that I use at work. That works fine but if the whole point is to learn new things, that’s not fulfilling the mission. Going with something completely different means that I’m expanding my horizons and pushing my comfort zone out more.

Starting to learn gRPC

I started reading gRPC Up and Running. Purchase it here.

I’ve finished the first two chapters of this book and my first impression is that it started out slow but quickly picked up pace and jumped right into the details. I still have a long ways to go before finishing the book but so far, I think I like it. I’ve dissected a small part of the first chapter and compiled some of my notes.

The g in “gRPC” stands for something different in every release. I didn’t know this. I just assumed that it stood for Google. Very clever.

The general process for developing a gRPC application is as follows:

  • Develop a service interface in a proto file
  • Generate server side code (server skeleton)
  • Generate client side code (client stub)

The client can invoke methods in your service interface. gRPC framework deals with all the complexities that includes handling strict service contracts, serialization of data, network communications, authentication, access control, observability, etc.

gRPC uses protocol buffers as the IDL (Protobuf). Protocol buffers are language agnostic and platform neutral. It is the mechanism used for serializing structured data.

gRPC is the child of many iterations of protocols that came before it. Some of those predecessors include:

  • Conventional RPC
  • SOAP
  • REST

It also discusses the downsides of REST.

  • Inefficient text-based message protocol
  • Lacks strongly typed interfaces between apps
  • Hard to enforce

More to come later but this is as much as I’ve gotten so far. I plan on writing and running their code examples for some hands on experience.