Mattias P Johansson, probably more well-known as @mpjme, is a YouTube’r with a focus on JavaScript and other programming-related topics. His YouTube channel “fun fun function” is packed with great videos. He has a wonderful presentation style has a knack for breaking down complex subjects into bite-size, understandable chunks. I highly recommend his videos. Subscribe and enjoy!
The video in question is #43 in the funfunfunction series and addresses a very important subject: “Does a developer need to be nice?”. I’ve written a summary of the video, and added a few of my thoughts a the end.
If you’re ready to get your feet wet, then go ahead and watch the talk. I’ve added more background information about the talk underneath if you aren’t convinced yet.
Working as a developer involves communication on many levels. We need to communicate with business stakeholders in a domain specific language, abstracting away much of the technical jargon. Team communication on the other hand is a lot more technical, and closer to our reality in code.
A lot of our communication is silent though. It happens through async tools like email, Skype or Slack. I’m sure that anyone that’s attempted communicating this way has experienced how easy it is to under-communicate, leading to a ping-pong of messages before the intent and understanding is conveyed.
The end goal of all this communication is software that delivers value to users.
Software isn’t finished when it’s been delivered though. It changes over time and with it loses its original intent. This leads to even more async communication, which can go over months or years. I’m talking about the communication that happens through the code we write.
This is a short summary / knowledge-well for two books I have “read” recently. I say “read” because I’ve actually listened to them in audiobook format. The books are:
The title of this post is a mix of my main take-aways from the two books. As with any compressed form of wisdom, though, it is quite inaccurate. I haven’t had the opportunity to write my own in-depth review, but I’ve written some of my thoughts and linked to a few others that have been more thorough.
Though not directly programming related, these books touch on some wonderfully core principles that are valid for any developer. From the analytical approach to thinking to how to create systems that increase your chances for professional and personal success.
This book wasn’t easy to consume as an audiobook for me. Listening to books is usually an activity I do while multithreading my life, like driving to work, mowing the lawn, vacuuming the house etc. I also didn’t view the accompanying PDF, which would have greatly aided in understanding the examples.
The topics here are thought-provoking, deep and eye-opening. I found the analogies of the two methods of thinking to be simple and accessible. Where System 1 is the fast, intuitive and lazy and System 2 is slow, thinking and costly. These analogies are easy to grasp, yet profound when put in to words and illustrated through experiments and examples.
Kahneman explains how we trick ourselves into making decisions based on false positives. The concepts of Cognitive Ease, Confirmation Bias and much more. These wonderful animated videos do a great job on touching on the main messages from he book, yet they barely scratch the surface. The many examples in the book really drive home the value of engaging your System 2.
System 1 is not without purpose though. It is the way we learn new skills and create habits. It allows us to free up valuable brain-cycles and energy to do other taxing tasks during our day. It is when we use System 1 to decide for us when System 2 should be engaged that we fall into making sub-optimal decisions.
I highly recommended this book. I’ll definitely need to revisit it some time in the future.
Beware the mixup of the two people’s reaction in “Big idea 5: Framing” in the first video.
How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life – 10/10
For those of you that may not know this, Scott Adams is the creator of the Dilbert comic strip. In this book he’s written his story and learnings on how he’s achieved success. He has a slightly different take on it than what many other success-stories tend to say.
Goals are for Losers. Systems are for winners.
– Scott Adams
The main take-away has been his quote on systems vs goals. His take on goals are that they are a fleeting target. Upon reaching a goal there is not further incentive to continue. When people with goals of losing 5 kilos achieve this there is a tendency that the weight comes back on at some time and you need to set new goals.
People with systems on the other hand are more likely to achieve long-term success since the aren’t focused on specific goals, but rather to put in place repetitive systems that will allow them to not only reach a proprietary goal, but also keep it going for the long haul. Eating and living healthy is a system that will lead to a better you with less chance of being overweight, and an increased chance of having more energy and keeping it that way for the rest of your life.
He also embraces the notion of luck, and increasing your luck-surface by putting systems into play that expose you to situations that luck will have a greater opportunity of finding you.
Doing things that increase your energy level is also a key point in increasing your general happiness. Eating well, being active and prioritizing.
The books light, quirky style make it a joy to read, and make the contents easily consumable. I enjoyed the book greatly and recommend it to anyone. If you’ve read and liked The 7 habits of highly effective people, you’ll enjoy this.
Here’s a video on the core concept of Goals vs Systems and a talk from Scott Adams himself on the topics from this book.
Finally
I think reading or listening to books to be of tremendous value and think and would like to promote the listening of audiobooks in this ever-so-hectic world. Embracing the non-technical side of life has also been of great personal value to me, and I hope you will also find joy in reading non-technical books.
Have you read any of these books? Would you also recommend them or possibly others? Should I add more in-depth reviews?
Just from reading from the title, you may have already made up your mind about what this article is all about (and you’re probably right). I’d also wager that if I’d said this directly to you, you’d be ready with a response just as I was uttering the last word. But do you really know what I mean? Why did I use those words? The need I’m trying to express? Which assumptions do you have when interpreting my words that lead to the immediate response or feeling you have now? The thing is, you suck at listening, and I do too.
Developers often find themselves in situations where we need to make decisions, weigh in our opinions and persuade others of our views. We often fail miserably by oversimplifying, jumping to conclusions or arguing. Our responses and thoughts are based on our experiences and assumptions. Which is great since it reduces the cognitive overhead of actually listening to each spoken word. Communication isn’t easy, but we can improve drastically by talking less and listening more. Continue Reading
Most developers can master the skill of listening to spoken words quite well. It’s easy to grasp words, run them through the compiler in our mind and spit out instructions. The compiler is based on sub-routines created through our life experiences, ready to give an output based on any input. These sub-routines remove the cognitive burden of weighing and considering each and every spoken word.
We spend our careers learning how to understand communication with compilers, yet struggle to effectively communicate with the people around us. Can we shift our built-in compiler to interpret words and actions in a way that opens us up to more empathic communication? Continue Reading
After my post on empathy as an essential skill, a commenter said that the most successful developers don’t need empathy, referring to John Carmack & Linus Torvalds. Not sure about John Carmack, but Linus certainly has had a brush or two with his lack of empathy when communicating with people. There is nothing to suggest that he lacks empathy, just that he on occasions doesn’t utilize it to its fullest. But this isn’t about how a man in the open-source community goes about his business…
Being a software developer is a tricky business. There are low’s and high’s lurking around every corner: Could this class be well-written, tested and a joy to work with or am I going to find regions of pain? Will the product demo be horrid and tedious or a joy for the stakeholders? Heated discussions, disagreements or blissful communication? Kind words or brutally honest feedback?
How can we keep up in this emotional roller coaster, while at the same time keeping up with the technology and our work? Could empathy be the secret ingredient in the awesomesauce of software development? This may very well be the case… Continue Reading
I stumbled over a slightly different manifesto the other day. Or it was a legion actually. Developers taking up arms against a travesty of the C# language: #regions. You can read it at http://anti-region-legion.org. So what is the legion all about? Here’s the message from the website:
The Anti-#region Legion is a community for people who believe that the C##region is an unfortunate part of the language.
I saw this and thought I was behind it completely, but decided to revisit my previous experiences and assumptions on the matter before concluding. Continue Reading
