Switch by Chip and Dan Heath - Notes

This page contains my notes, my reflections and various other references that would aid my readers. Finally my recommendation on the book.

Book: Switch - Switch - How to change things when change is hard

Authors: Chip and Dan Heath

Website: http://heathbrothers.com

Posts:

These posts are not a replacement for the book. The book is million times impressive and insightful. After reading these posts you might get an urge to buy the book but after reading the book you would like to change something. I would rate this book a five star (*****) and encourage all my readers to buy one. These posts should shed some light on your investment on this book and potential huge return on investment.

1. Book Review after first reading
2. Switch (Part 1) - Three Surprises
3. Switch (Part 2) - Direct the Rider, Find the Bright Spots
4. Switch (Part 3) - Direct the Rider
5. Switch (Part 4) - Motivate The Elephant
6. Switch (Part 5) - Shape The Path
7. Switch (Part 6) - How to keep the Switch going?
8. Found an excellent video review of the book in Youtube
9. Other Resources to aid in learning

!!! Happy Switching !!!

Interviewer Essentials

A great part of my weekend goes to interviewing and a considerable amount of my time during my weekdays is devoted to hiring and activities related to hiring - profile screening, talking to the candidates, interviewing - technical and softer aspects.

What I learned are (over a period of time)

To Interviewers and to their managers (the source of problem but who think that the fault is on everyone but them)

1. In the part of the world that I live in especially - be ready to read more (do not get bored or scared of seeing the projects and skills that one acquired 10 years back that never eroded)
2. Shortlist quickly and ask HR to schedule interview
3. Be available on time. If you have some work and you would join late, send someone who can do interviews (not just filling the space/time)
4. Interviews are a business transaction. The interviewer has to sell the company and the future employee is likely to undergo. Not a fancy future that would never materialize. Be pragmatic on what you say
5. You cannot get super-man when you pay peanuts. Reset your expectations
6. Expect that someone can become super-man after she joins. Look for track record
7. People want career, money, satisfaction, appreciation, feedback and a great culture (only the order differs from people to people). Do not oversell anything (as people might feel they won't get other stuff)
8. You may be leading machine critical things but do not expect the folks to burn might night oil. Do not boast either
9. Interview for the position (do not interview like you are hiring a CEO when you are hiring a developer). It is big sin to hire a developer without coding. Satisfied with pseudo code or "I can tell the logic" is the biggest sin. If you are hiring for senior position, start with design and drill down to coding (or start with code and move to design - bottom-up or top-down either way is fine, but do it)
10. Often neglected piece is asking them to write unit tests for their own code. They might even write just two test cases, but it is fine. The question is whether they "think". If someone is allergic to writing unit tests - never look back
11. Giving clues is not a sin. When you give hints, you really know more about the candidate (whether he picks up quickly and able to connect the dots). When you give clues, ask them to enhance.
12. Do not ask funny or fancy questions on DS and Algo (which you were not able to solve for three hours but once you solved you want others to solve in 10 minutes) when your daily work is something else
13. The world is moving more towards OpenSource, please see whether the candidate has allergy towards the word - OpenSource (and self-learning/training/exploring on their own)
14. Give them the runway - Not all will be able to crack everything first and not always. Warm them up
15. Listen properly and be attentive. Ask questions and answer questions properly
16. Most often you will learn things from others, interviewing is no exception
17. Decide as soon as the interview is over. Overthinking is killer
18. Help HR. Maybe they have so many candidates to take care. Pick your resume, invite the candidates and take care of interviews. Keep HR informed on outcomes
19. If the candidate asks feedback, spend some time with them in giving feedback (especially if they are very junior to you and looking to improve themselves). You never know when you will work for a nerd
20. No frustration (even if your day is tiring)
21. After hiring, connect with the candidate. Try to see whether you can be of any use to them.
22. Wait for them to join
23. Most importantly - remember that you are hiring a human, not a machine. Behave appropriately

Of course, this is not the bible to do interviews and there are zillions other things to do.

Your comments?

"Python Crash Course by Eric Matthes" - Reading Journal 1

Like me, if you are new to Python and want to quickly ramp-up to become no non-sense developer in Python, you might want to read this post, these posts that are related to this book and probably all of these posts to become Python Super Star.

The best book to start (even if you are already exposed to some level of programming) is "Python Crash Course by Eric Matthes. The book consists of two parts. Part one is basics with 11 chapters and Part two consists of nine chapters with three projects. The main intention of this book is to get us up to speed in Python quickly (as you might have guessed it from the title).

The rest of the post gives an overview of what I learned in Chapters 1, 2 and 3 and what was interesting/boring. I ensure to keep it crisp so that you spend more time on learning rather than reading my stories.

Chapter 1: Getting Started
While many of us fumble when it comes to doing things for the first time, this chapter takes the installation of Python and running the first program to the extreme. All the folks who have exposure to programming to a decent degree will find it very boring (detailed steps in Windows, Mac, and Linux deserve their space in the appendix but not first chapter). What I would expect is some history of Python, principles of Python, Why Python is so popular, Where Python is used and what is the future of Python. My view is that you should download and install Python on your own and probably try run your first program (it is fine if you spend additional 15 mins to muck around and figure it on your own - believe me, it is easy). This chapter is a dull start.

Chapter 2: Variables and Simple Data Types
This chapter covers quite a lot of ground if you not exposed to programming at all. If you are experienced programmer, you will skim this chapter through but yet feel accomplished if you do all the exercises. This chapter talks about Variables, naming variables, data types - string, integers and float with some important operations on those datatypes in Python. The concluding sections of this chapter deal with importance of writing comments and The Zen of Python which in my view placed right at chapter 2. This chapter should take 30 minutes to an hour depending on whether you are a programmer or aren't. Python seems to be exciting

Chapter 3: Introducing Lists
This chapter covers an important aspect of Python - that is Lists. After reading this chapter and working out the examples/exercises one should get a fair handle on lists. Like me, if you are from C world you will find it to have some similarity with arrays but then it differs in varieties of ways. You will start feeling the uniqueness and flexibility of Python when you try out examples. This chapter should take around one hour to read and workout examples (since you are no longer new to Python). By now, you can expect yourself to start becoming comfortable with Python. This chapter was a treat for a newbie. Enjoyed it.

If you wish to join me in the journey of a lifelong student, add yourself to my blog list and I will not disappoint you :-). Together, let us transform ourselves.

Learn Python with "Python Crash Course by Eric Matthes" - Getting Started

I found an excellent link that has recommendations for Python books. Looks like the most of the books are well rated on Amazon and I thought that I would start learning Python with little more focus and discipline.

First I would like to get started with the book "Python Crash Course" by Eric Matthes. The book promises that it would be a crash course with a hands-on approach with three projects after learning the basics of Python. I feel that it would be easier for me to boot-up in Python using this book by doing some projects. I expect to complete this book in 3-4 weeks time (depends on how much time that I am going to devote and most likely I will utilize my weekends).

As usual, I prefer reading this book twice and do things as I read the book the first time. The second reading is to fill the gaps and to ensure that I do not miss anything and probably refactor the code I have written. After I complete the book, I will write a full review of the book with pointers to the source code of the projects in a public repository like GIT and give my feedback on whether this book satisfied my expectations (I am also planning to write short summaries of chapters - what I learned, what I felt interesting and what is boring)

My expectations - Learn Python, interesting to read, interesting projects to do, some advice to programmers new to Python, Fast track my Python boot-up and guidance to go to next level in Python

Let me see whether this book satisfies me.

If you wish to join me in the journey of a lifelong student, add yourself to my blog list and I will not disappoint you :-). Together, let us transform ourselves.

Wired to be Weird?

Journey of you and me

1. Human mind is fresh when born
2. Few days after you are born, the folks around you condition you (smile is an outcome of happiness, boy doesn't cry, so do not cry, a girl should not do this)
3. Because of extreme conditioning, you build your faith
4. You associate yourself with others of similar faith (things are fine till this)
5. You tend to believe that the person who you associated with is "good" because of what you experience with him (which is ok, but things start to go bad). Instead of you liking a quality or a task, you tend to like that person
6. Assume that the person exhibit some unusual behavior
7. Since you like that person, you are actually discounting the unusual behavior (which is not good) and if you like that person to extreme, you actually justify his behavior

And therefore - 

1. We are weird and as the result, we regress
2. We regress and feel bad, understand our hardware (brain - how it is wired) and try to change our software (thinking/awareness). We grow (a nice possibility)

Logic without Logic

I came across an wonderful quote in a book on Discrete Mathematics. It applies to several things in life and our attitude in life. Here it goes 

Symbolic logic has been disowned by many logicians on the plea that its interest is mathematical and by many mathematicians on the plea that its interest is logical. - A N Whitefield

Inference: And as a result it is disowned by both.

Apply to Life: I have been in this is situation several times. For instance, when you study mathematics (or any complex subject that needs hard work to master) in school we hear teachers saying that you will understand it much deeper when you go to college. And after a couple of years when you are in college, your lecturer will say "you would learnt it in school" and just skim through it. 

We often get caught in the tiny window of ignorance due to negligence (when people treat you under qualified when you are young and over qualified when you are old and as a result you never get qualified). Break the window

Internship for Students

Writing this after a while. 

I was thinking of doing something like this for a very long time (many years probably) but took while. Dr. Sankaran's post is one of the reasons [Thank you Sir]

Hope you guys still remember OpenGyan. I am planning to do something similar but for folks who are really want to take programming to next level. The thinking is to come up with real world problems and TRY solving it and on the way you will learn some cool things. It will be like internship (of course with no stipend).

Program Structure:

1. Identify folks who are interested to do this. Ideally someone with good (this is purely relative) programming skills and willing to put efforts to learn something new. Should be doing graduate or post-graduate course in a college (and interested in computers)
2. Willingness to put 4-5 hours of efforts per week. I think this will be a big differentiation. 
3. Willingness to work in latest technologies - cloud/containers/tools/http/REST (some of these are highly talked about in industry)
4. Has Google hangout or similar tool for interaction
5. Talking to geeks and learning from them (expands your learning)
6. Planning to do for two teams each containing not more than two people. The members of team are co-located (either from same college or live near by each other or connected by Google hangout in the order of preference)
7. Finally a demo of your work (a write-up on what you have done and learnt) and move on to next problem (if you are still interested)

What you will probably get (no guarantee):

1. Problems that the world is trying to solve (tough part)
2. How some of the problems are solved (easy part once tough part is found)
3. Get hooked to problems (disciple)
4. Apply what you learnt. If you have not learnt anything, learnt it first and apply it (consistency)
5. Learn tools that professional use to debug/solve problems (smart work)

What you pay:

• Your fee is through your commitment and valuing the folks' bandwidth
• No exchange of money or favour to be involved

If you are interested - write to me GRABYOURFREEDOM AT GMAIL DOT COM

If you feel it will help someone that you know (or don't know) - Just Share.

Programming Language Pragmatics [Chapter 1, Section 1.5] Check Your Understanding

This post has my answers for "Check Your Understanding" questions in section 1.5, Chapter 1 of the book Programming Language Pragmatics by Michael L. Scott.

Chapter 1, Section 1.5 - Check Your Understanding

Question # 11. Explain the distinction between interpretation and compilation. What are the comparative advantages and disadvantages of the two approaches?

Compiler produces machine code from high-level language. After the compilation, the machine code can be directly run on the target system which is locus during runtime. The machine code produced on one architecture cannot be run on a machine with different architecture. The compiled program is faster than its interpreter counterpart.

The interpreter is usually the locus when the program is running. The program written in high-level language is directly run on the target machine through interpreter. In a sense, the high-level code is machine instruction for interpreter. Most of the interpreter are slower in execution as most of the decisions during the course of the program are deferred until the control reaches to the particular statement. However the debugging is much more easier to do in interpreter as interpreter has control throughout the execution of the program. Moreover the interpreter can do useful features like on-the-fly compilation so that the program can generate code during execution which is again consumed/executed by interpreter.

Question #12. Is Java compiled or interpreted (or both)? How do you know?

Java is both compiled and interpreted. Java compiler transforms Java source code to bytecode. Java Virtual Machine (interpreter) executes bytecode.

Question #13. What is the difference between a compiler and a pre-processor?

Pre-processor is needed step before compilation. Compilation transforms the code substantially but pro-processing is usually is light-weight such as removing comments, replacing macros etc.

Question #14. What was the intermediate form employed by the original AT&T C++ compiler?

The intermediate form produced by AT & T C++ compiler is "C".

Questions #15. What is P-code?

P-code is intermediate code that are produced by Pascal compiler. P-code is run by Pascal interpreter during runtime.

Question #16. What is bootstrapping?

Typically the programming language compiler is written by itself meaning that a C compiler is usually written using C. However at first there will not be any compiler to compile the code written in C. Usually a tiny interpreter is written in a different language to produce machine instruction (tiny compiler). Later the tiny compiler produced by interpreter is used to compile the compiler. This is called bootstrapping. In similar fashion more features are added incrementally to produce high quality compiler.

Question #17. What is a just-in-time compiler?

Just-in-time compiler is a feature of interpretor that converts byte-codes to machine instruction while the program is under execution. This is done mainly to increase performance (speed of execution)

Question #18. Name two languages in which a program can write new pieces of itself "on the fly"

List and Prolog (Python, Perl, TCL also have similar features)

Question #19. Briefly describe three "unconventional" compilers - compilers whose purpose is not to prepare a high-level program for execution on a microprocessor

1. SQL - Translates statements to operations on database
2. Compilers to translate logic-level circuit specification into photographic masks for computer chips
3. TEX that translates document to commands for printers

Question #20. List six kinds of tools that commonly support the work of a compiler within a larger programming environment

1. Debuggers
2. Editors
3. Pretty-Printers
4. Style Checkers
5. Configuration Management
6. Profilers

Question #21. Explain how IDEs differs from a collection of command-line tools

All the tools are integrated in an environment often collaborates amongst themselves where as the command line tools are used merely in isolation. For example when a program crashes, IDE points which line of the code is causing the issue and pops up the code in the editor. The developer can make the change and save the file. IDE automatically builds it.

Programming Language Pragmatics [Chapter 1, Section 1.3] Check Your Understanding

This post has my answers for "Check Your Understanding" questions in section 1.3, Chapter 1 of the book Programming Language Pragmatics by Michael L. Scott.

Chapter 1, Section 1.3 - Check Your Understanding

Question #1: What is the difference between machine language and assembly language?

Machine language is written using the instructions set of the processor directly. Each operation supported by the processor is given a code using which the operation is carried out. The code written in Machine language will be in hexadecimal. But in the case of assembly language the program is written using mnemonic (often represented as operations such as MOV, STORE, ADD, SUB etc) which later translated to machine instructions by software called assembler. The assembly language also has provisions for macro definition which expanded by assembler before producing machine code.

Question #2: In what way(s) are high level languages an improvement on assembly language? In what circumstances does it still make sense to program in assembler?

While assembly language is faster to execute, high-level languages can be easily learnt by programmers, ported to varied architecture without requiring to rewrite entire logic on many architectures and saves programmers time since high-level languages are not one-to-one mapping of machine instructions. High level languages often use functions (in the context of mathematical functions) to produce highly expressive code. However assembler will be default choice for system specific performance reasons.

Question #3: Why are there so many programming languages?

There are several programming languages because of the following reasons - evolution, special purpose, personal choice, 

Question #4: What makes a programming language successful?

The programming languages are successful because of one or several of the following reasons - expressive power, Ease of use, ease of implementation, standardization, open source, excellent compilers, economic, patroage and internia.

Question #5: Name three languages in each of the following categories: von Neumann, functional, object-oriented. Name two logic languages. Name two widely used concurrent languages

von Neumann - C, Ada, Fortran

Functional: Haskell, ML, Scheme

Object-oriented: Java, C++, Smalltalk

Logic Languages: Prolog, spreadsheets

Concurrent Languages: C++, Java 

Question #6: What distinguishes declarative languages from imperative languages?

Imperative languages solves a problem by sequence of steps with each steps produces some side effects. The imperative language focuses on how a problem should be solved rather than what to do. The declarative languages on the other hand focuses on what needs to done.

Question #7: What organizations spearheaded the development of Ada?

US Department of Defence

Question #8: What is generally considered the first high-level programming language?

FORTRAN?

Question #9: What was the first functional language?

Lisp, Scheme?

Question #10: Why aren't concurrent languages listed as category in Figure 1.1?

Concurrency support is available in many of languages such as Java, C++ and C. Several concurrency packages are available as language extensions

Abstraction - Events IN, Solutions OUT

Abstraction is a great tool for mankind. The history of human evolution has seen uncountable number of evidences on the usefulness of abstraction. Abstraction is to absorb important attributes and leaving out unimportant attributes. Very state that we are in is the fruit of our ability to abstract - Ideas.

Ideas - what are ideas. Ideas are fruits of abstraction of events happening around us or impulse of information that happens elsewhere (which again an event to us). In problem solving domain, ideas are output of abstraction (elevated thinking) and inference (desirable response from higher plane of thinking). 

While most of us think creativity is for people who are brainy. But the truth is that the creativity is fruit of hard work, systematic way of abstracting the problem and connecting those events with our experience. Like anything, it is only the practice that makes it smart work. The first step towards solving problems is to understand a problem or rather find/recognize a problem, understanding it at higher plane and giving way for ideas to emerge. 

Abstraction is what it took us where we are and it is the only thing that is going to take us where we ought to go.

PS 1: This is hangover of reading programming languages pragmatics which i think is a wonderful book. I will be reading for next several months (so surely there are going to be numerous posts on that)

PS 2: I am posting after an year. I have to admit that i ran out of ideas and since i am reading a book i think i will get a lot more ideas

Fallacy and Bias

Most of the times we think we are "sound" and better than others. We keep carrying this in our head - "if you take average score of intelligence, i am above average than most of the people". We fail to understand that all of us feel the same way. 

When you think you are better than your neighbor, your neighbor thinks he is better than you. If this is true, the average will be lower than individual scores. This clearly shows that we have fallacies and biases. The things we think are NOT what we think. Our concept of being neutral or unbiased is more biased towards us. This is a paradox. Ex: We often think that we are modest and in fact we "say" so - "i am modest".

Feel happy - everyone is wired that way. 

Our brain works and everyone's brain is wired for biases and fallacies. Our excellence lies in knowing these biases (making us counter productive) and putting checkpoints to bring some sense - an order from chaos. Only when we understand our biases and put some checkpoints, we will be making some sense.