This was the first book listening experience that I’ve actually finished. Sean Runnette‘s voice was adequate for setting the tone and rhythm – actually, sometimes I felt I was listening to Feinmann himself!
Having read Surely You’re Joking, Mr. Feynman!, What Do You Care What Other People Think? and some other papers/videos, most of the stories in the book I already knew, but it had some new material that made it interesting nonetheless. This is more mathematical/physical intense than the others, probably because it’s mostly focused on the scientific and less in the human Feynman – but also because many chapters are directly transcribed from conferences he gave. It’s also worth noting that, unlike the other two, this book was published without Feynmann intervention: it’s published 10 years after his death.
If I had to choose only a Feynman book I’d choose Surely You’re Joking, Mr. Feynmann! It’s better edited and has more variety. Then, if you are hungry for more, What do you care what other people think? contains new stories. I liked this one, but I doubt it’s a good introduction to Feynmann lifestyle, work, values, and character.
I’ve just finished the book Code Simplicity. It presents a framework for thinking about software development in the form of laws and rules. It’s short but comprehensive. From my experience, the laws and rules hold true. I think the book has value as an overall perspective of what’s important in software development, and there are some chapters that are really spot on: for example, the equation of software design – something that I’ve already included in my glossary and plan to expand.
Code Simplicity doesn’t intend to land the laws and rules to something actionable, though. I’m at a point in my career where I’m focused on consolidating and reflecting upon how to achieve simplicity in software design – that means that I crave for specifics so I can compare them with mine.
As a cross-recommendation, if you are interested in learning about the laws of software development in a manner that is actionable, I’d suggest reading the Beck’s trilogy: Extreme Programming Explained: Embrace Change, Test Driven Development: by example, and Implementation Patterns. Those three books make a great combination of macro-forces (at a project level) and micro-forces (at a coding level) in software design. They were fundamental in consolidating my experiences as a programmer, so I’m highly biased towards them.
Hat tip for the Code Simplicity recommendation: Nikolay.
One of the things I was very into a decade ago was studying the intertwine between technology, culture, and society. From those years, I developed a sensitivity about my role as an engineer, or as an enabler of possible worlds.
This is one of the things I wanted to avoid:
If you have ever had a problem grasping the importance of diversity in tech and its impact on society, watch this video pic.twitter.com/ZJ1Je1C4NW
A person isn’t able to clean his hands because the machine sensors are only prepared to detect white hands! That’s a horror story that could make a BlackMirror episode.
This made me think about the mainstream perception of Machine Learning and Artificial Intelligence technology. Lately, some friends of mine are sharing with me clickbait news like Facebook shuts down robots after they invent their own language. They ask me if robots could take over, soon. Well, I can tell you something: at this stage of technology, I am not worried about robots taking over. What I do worry about is how our inability to understand technology creates racists algorithms that reinforce our biases.
(…) the number-one indicator of a successful team wasn’t tenure, seniority or salary levels, but psychological safety. Think of a team you work with closely. How strongly do you agree with these five statements?
If I take a chance, and screw up, it will be held against me
Our team has a strong sense of culture that can be hard for new people to join.
My team is slow to offer help to people who are struggling.
Using my unique skills and talents come second to the objectives of the team.
It’s uncomfortable to have open honest conversations about our team’s sensitive issues.
Teams that score high on questions like these can be deemed to be “unsafe”. Unsafe to innovate, unsafe to resolve conflict, unsafe to admit they need help.
What’s the purpose of this code? It takes some input data structures and outputs a markup, either proper HTML or a code to be processed by later stages of the pipeline. At the core, what we are doing is taking a decision based on the input’s state so it can be modeled as a decision tree:
By restating the problem in a more simple language, the structure is made more evident. We are free of the biases that code as a language for thinking introduces (code size, good-looking indenting, a certain preference to use switch or if statements, etc). In this case, conflating the two checks into one reduces the tree depth and the number of leaves:
Current status: completely mesmerized by this song.
I couldn’t find a live version worth sharing, though.
In this paper, we make the case that the high-productivity digital firms are starting to generate a new middle class. It’s a virtuous circle. Consumers flock to those firms because they offer lower prices and better service. Workers migrate there from low-productivity firms because the high-productivity firms offer better wages for the same occupations—and, often, steadier hours and better benefits.