What Do You Read These Days? #3

What Do You Read These Days? #3

This is the third post in my series What do You Read These Days. In case you love reading books and you missed the previous two, make sure to check them here and here. My goal is to share personal opinions and views on the books I read and inspire some of my readers to broaden their views, by reading literature which may be outside their primary area of interest. In these posts I tend to present two books, of which one is usually purely technical (in the terms of programming generally).

1) Thinking, Fast and Slow

No alt text provided for this image

Have you ever wondered how exactly are you making everyday decisions? How do you drive conclusions about what is "right" or "wrong"? And are you aware that in certain cases, you are making a wrong decision, despite being sure it is the right one?

Daniel Kahneman is famous for his work in behavioral economics, for which he received the Nobel Memorial Prize. In case you didn't know (like myself), while this is not the original Nobel Prize we typically think of, it's considered as Nobel award for Economis. Kahneman is also known for contribution in the area of psychology of decision making.

In this book, the author explains the two systems that drive the way we think. These he calls System1 (S1) and System2 (S2). S1 is fast, intuitive and emotional, while S2 is slower and more logical. We generally make decisions quickly with the S1, often because S2 is simply lazy.

For example, as Kahneman puts it, here are some actions contributed to S1:

  • Detect that one object is more distant than the other
  • Answer to 2x2
  • Detect hostility in a voice
  • Drive a car on an empty road

In comparison, here are few actions contributed to S2:

  • Check validity of a complex logical argument
  • Look for a woman with white hair
  • Search memory to identify surprising sound
  • Maintain a faster walking speed than is natutal for you
  • Fill out tax form


Another example. When you see:

17x24

S1 knows the result is not 45, and neither it's 54300, however it's not sure whether it's 568. In order to compute it, you will have to put S2 in action. If you attempt to compute this in your head, you will first retrieve from the memory congnitive program for multiplication you learned in primary school. Then you will implement it. Carrying out this operation is a cognitive strain - you felt the burden of holding too much material in your memory, as you needed to keep track where you were, and where you were going. The computation was not the only event in your mind. Your body was also involved. Your muscles tensed up, your blood pressure rose and your heart rate increased.

I loved this book as it explains when we can and cannot trust our judgement. It ultimatelly transformed the way I think about thinking itself and decision making. While reading it, I have had many "ah, so this is what's happening inside my brain" moments. Book also helped me develop a new skill - to identify when I need to involve S2 and be mindful about it. This of course most commonly happens while solving of the intensive problems in my every day work, but being aware of it, makes it easier, to a certain degree.

Below I share some of the quotes and parts of the book I liked.

"It is easier to recognize other people’s mistakes than our own."

"Laziness is built deep into our nature. "

"When people believe a conclusion is true, they are also very likely to believe arguments that appear to support it, even when these arguments are unsound. "

"A reliable way to make people believe in falsehoods is frequent repetition, because familiarity is not easily distinguished from truth. Authoritarian institutions and marketers have always known this fact. "

"People are prone to apply causal thinking inappropriately, to situations that require statistical reasoning."

"The stubbornness of an intelligent person is seen as likely to be justified and may actually evoke respect, but intelligence in an envious and stubborn person makes him more dangerous. "

"The proof that you truly understand a pattern of behavior is that you know how to reverse it. "

"You are more likely to learn something by finding surprises in your own behavior than by hearing surprising facts about people in general. "

"Rewards for improved performance work better than punishment of mistakes."

"People tend to focus on a few striking events that happened rather than on the countless events that failed to happen. "

"The poorer man will happily pay a premium to transfer the risk to the richer one, which is what insurance is about. "

"Organisms that treat threats as more urgent than opportunities have a better chance to survive and reproduce. "

"Brain recordings also indicate that buying at especially low prices is a pleasurable event. "

"The brains of humans and other animals contain a mechanism that is designed to give priority to bad news. By shaving a few hundredths of a second from the time needed to detect a predator, this circuit improves the animal’s odds of living long enough to reproduce. "

"Because of the possibility effect, the worry is not proportional to the probability of the threat. "

"[Insurrance] People buy more than protection against an unlikely disaster; they eliminate a worry and purchase peace of mind. "


2) Refactoring - Improving the Design of Existing Code

No alt text provided for this image

By definition, refactoring is about improving the design of existing code, without altering its core behavior.

What can I say, this is the book that most software engineers argue to be one of the most important any programmer can read. It changes the way you think about your code. It changes your approach to it. Essentially, it shows the beauty of creating the computer program. The idea of refactoring is something I myself have never learned prior to reading this book. Not saying it's anyone else's responsibility, but it's something you don't learn in school, Univercity or in my case, during regular work as a Verification engineer. It is not only an important skill to develop, it also helps you develop a crucial mindset, when it comes to creating computer programs.

Examples given in this book are in JavaScript, of which I have zero knowledge, but after few pages, I started to pick up the pattern. This is also one of the perks of reading a book like this: new neural pathways are bound to be made in your brain, as you explore something new and different.

Book is way too technical for broad audience, but I did extract a few quotes which I find very interesting.

"Refactoring is the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when you refactor, you are improving the design of the code after it has been written."

"With refactoring, the balance of work changes. I found that design, rather than occurring all up front, occurs continuously during development. As I build the system, I learn how to improve the design. The result of this interaction is a program whose design stays good as development continues."

"After all, the compiler doesn’t care whether the code is ugly or clean."

"A poorly designed system is hard to change-because it is difficult to figure out what to change and how these changes will interact with the existing code to get the behavior I want"

"When you have to add a feature to a program but the code is not structured in a convenient way, first refactor the program to make it easy to add the feature, then add the feature."

"Refactoring changes the programs in small steps, so if you make a mistake, it is easy to find where the bug is."

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

"The true test of good code is how easy it is to change it."

"As people change code to achieve short-term goals, often without a full comprehension of the architecture, the code loses its structure."

"Programming is in many ways a conversation with a computer. I write code that tells the computer what to do, and it responds by doing exactly what I tell it. In time, I close the gap between what I want it to do and what I tell it to do. Programming is all about saying exactly what I want. But there are likely to be other users of my source code."

"As Ward Cunningham puts it, by refactoring I move the understanding from my head into the code itself."

"Some organizations do regular code reviews; those that don’t would do better if they did. Code reviews help spread knowledge through a development team. Reviews help more experienced developers pass knowledge to those less experienced. They help more people understand more aspects of a large software system. They are also very important in writing clear code. My code may look clear to me but not to my team."

"Reviews also give the opportunity for more people to suggest useful ideas. I can only think of so many good ideas in a week. Having other people contribute makes my life easier, so I always look for reviews."

"Although many people see time spent refactoring as slowing down the development of new features, the whole purpose of refactoring is to speed things up."

"Good programmers know that they rarely write clean code the first time around."

"A heuristic we follow is that whenever we feel the need to comment something, we write a function instead."

"Global data illustrates Paracelsus’s maxim: The difference between a poison and something benign is the dose. You can get away with small doses of global data, but it gets exponentially harder to deal with the more you have."

"The fundamental rule of thumb is to put things together that change together."

"When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous."

"Now I’m a pretty lazy person and am prepared to work quite hard in order to avoid work."

"Naming things well is the heart of clear programming."

"Any variable with more than one responsibility should be replaced with multiple variables, one for each responsibility. Using a variable for two different things is very confusing for the reader. "


What do you read these days? Have you recently read a book which was out of your primary area of expertise and what did you learn from it?






要查看或添加评论,请登录

Milos Mirosavljevic的更多文章

  • SoC Verification VS Traditional (UVM) verification

    SoC Verification VS Traditional (UVM) verification

    "But why can't I just use our UVM testbench to verify SoC behavior?" I often hear junior engineers or those who have…

    33 条评论
  • PCIe vs. CXL vs. UCIe

    PCIe vs. CXL vs. UCIe

    Many years ago, my first project was related to PCIe Gen 3. Before that, I only encountered simple protocols UART…

    14 条评论
  • The Packaging of Microchips: 2D vs 2.5D vs 3D Integration

    The Packaging of Microchips: 2D vs 2.5D vs 3D Integration

    When we think about microchips, we often imagine tiny rectangles packed with billions of transistors. We imagine the…

  • SoC vs. Chiplets: What’s the Difference?

    SoC vs. Chiplets: What’s the Difference?

    In the world of hardware design, you’ve probably heard the terms System-on-Chip (SoC) and chiplets. Both are critical…

    21 条评论
  • Emulation vs. Prototyping: What’s the Difference?

    Emulation vs. Prototyping: What’s the Difference?

    If you work in hardware verification, you’ve probably heard about simulation, emulation, and prototyping. You probably…

    8 条评论
  • Debugging by Eliminating Potential Causes

    Debugging by Eliminating Potential Causes

    For verification engineers, the ability to quickly debug and diagnose test failures is an essential skill. My…

    3 条评论
  • How Saying "no" Helped John Become a Stronger Technical Leader

    How Saying "no" Helped John Become a Stronger Technical Leader

    John is a hardworking and highly motivated engineer who had just started leading others. He was driven by a desire to…

  • Ever heard of AWK programming language?

    Ever heard of AWK programming language?

    I encountered awk for the first time many years ago while attempting to produce a script that would effectively search…

    6 条评论
  • Apply the 80/20 principle to efficiently learn SystemVerilog

    Apply the 80/20 principle to efficiently learn SystemVerilog

    I vividly remember my career start as a verification engineer: it was in late 2011, in the cold November (this reminds…

    6 条评论
  • Initiative - Hidden Gem In Your Skillset

    Initiative - Hidden Gem In Your Skillset

    Andrew, a young engineer, started his career like most others in his profession – eager to prove his worth and learn a…

    2 条评论

社区洞察

其他会员也浏览了