TL;DR

In this post, I'm sharing my ultimate list of books on the topics of leadership, personal improvement, goals, finance, purpose, and programming.

!TL;DR

The book to read is not the one that thinks for you but the one which makes you think.

~ H. Lee

As it usually goes with people that read, you're often asked to share "a few good books".

I already wrote about the top 5 that are, IMHO, worth re-reading every once in a while, in the post Too many books, not enough time.

However, this time I'm sharing my ultimate list of books on the topics of leadership, personal improvement, goals, finance, purpose, and programming. Each and every one of these books helped me move the needle a bit forward, so I hope they'll do the same for you.

I didn't list any fictional books here, but if you want one, then look no further than The Name of The Wind.

Leadership

• Leadership and Self-Deception
• The First-Time Manager
• Leading snowflakes
• Radical Candor
• The Manager’s Path
• The Five Dysfunctions of a Team
• The Leadership Handbook
• Leaders eat last
• Start with Why

Personal improvement for leadership

• The Coaching Habit
• How To Win Friends and Influence People
• The 7 Habits of Highly Effective People
• Speak to Win
• Time Management Made Simple
• The ONE Thing

Personal improvement in general

• The miracle morning
• Mindset
• Can’t Hurt Me
• Make Your Bed
• Discipline Equals Freedom
• The 5 Second Rule
• So Good They Can’t Ignore You

Have goals and think big

• Goals
• Choose Yourself
• Edgy conversations
• Big Magic

Purpose

• How Will You Measure Your Life
• The Monk Who Sold His Ferrari
• The Road Less Traveled
• The four agreements

Finance

• Rich Dad Poor Dad
• Think and Grow Rich
• The Greatest Salesman in the World
• The Science of Getting Rich

Programming

• Soft skills
• Code complete 2
• The passionate programmer

Conclusion

This list may seem daunting, but then again, please remember that if you only read 25 minutes per day, you'll read 30 books per year.

If you think I should add another one to this list, please let me know in the comments.

Here are my highlights from a highly recommended book The Manager’s Path by Camille Fournier.

Management 101

• 1on1 meetings with your direct manager are an essential feature of a good working relationship.
• The bedrock of strong teams is human connection, which leads to trust. And trust, real trust, requires the ability and willingness to be vulnerable in front of each other.
• Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.
• Bring agendas to your 1on1s when you have things you need to talk about.
• When you want to raise, ask for it. When you want the promotion, find out what you need to do to get it. Your manager cannot force work-life balance on you. On the flip side, sometimes if you want a bigger job, you will have to work more hours to get it.

Mentoring

• Listening is the first and most basic skill of managing people.
• Mentoring new hires is critical. Mentoring an intern: give them a project and make them present the work.
• Alpha geek tries to create a culture of excellence but ends up creating a culture of fear. If you’re ever in a position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role.

Tech Lead

• The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best coach, is a common misconception that even experienced managers fall for.
• Tech lead is a leader, responsible for a software development team, who spends at least 30% of their time writing code with the team.
• I have a strong opinion on pushing people into management, which is that you shouldn’t do it.
• Real-life of a manager: when you only had a team you were able to balance things and still write code, but as your team has grown you’ve lost touch with the code. It’s troubling you as something you should be doing, but there’s no time.
• Successful leaders write well, they read carefully, and they can get up in front of a group and speak. Don’t forget to listen during all of this communication.

Managing people

• It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.
• Regular 1on1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. The default scheduling for one on ones is weekly.
• Some people assume that good relationships require very little attention, and spend all their time on their bad relationships.
• As much as possible, when someone does something that needs immediate correct feedback, don’t wait for the 1on1 to provide that feedback. The same goes for praise!
• When you strip creative intelligent people of their autonomy, they lose motivation very quickly.
• The worst micromanagers are those who constantly ask for the information they could easily get themselves.

Managing a team

• Leaders are capable of identifying the highest value projects and keeping their team focused on this project. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.
• If you truly wish to command the respect of an engineering team they must see you as technically credible. You need to stay enough in the code to see where the bottlenecks in-process problems are. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.
• Infrequent releases can hide the pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers don’t know how to break the work down.
• Project management rules of thumb:
  • Do you have 10 productive engineering weeks per engineer per quarter
  • Budget 20% of the time for generic sustaining engineering work across-the-board
  • As you approach deadlines, it is your job to say no
• Test of happy engineering team: “If you buy them pizza in the evening, will they stick around and socialize together, or will they race out the door as quickly as possible?“
• Whenever asked for an estimate, take your guests and double it.

Managing Multiple Teams

• The engineering director
  • is responsible for a significant area of the technology team. Leads engineers across multiple product areas, or multiple technology functions. He is not generally expected to write the code on a day to day basis. However, the engineering director is responsible for the organization's overall technical competence, guiding and growing that competence in the whole team as necessary through training and hiring.
  • should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry.
  • focuses on ensuring that we continue refining our development/infrastructure standards and processes to create technology that will deliver sustained value to the business. They are leaders for recruiting, headcount management and planning, career growth, and training for the organization. They’re responsible for creating and growing the next generation of leadership and management talent in the organization, and helping the talent learn how to balance technical and people leadership and management.
  • is a motivated, cross-functional collaborator, a very strong communicator, and has a positive public presence.
  • should spend the time to gain mastery of programming before moving up to management.
  • spends at least a solid half-day once a week completely free from meetings or other obligations and uses this time on some creative pursuit (blog post, conference talk, open-source project).
• One example of an important but not urgent task is actually preparing for meetings so that you can guide them in a healthy way.
• Engineers who don’t write tests often have a harder time breaking down their work.
• Frequency of changes is one of the leading indicators of a healthy engineering team.

Managing managers

• You must take the time to proactively hold skip-level meetings with the people who report to your direct reports (once a quarter).
• Learning how to hold managers accountable will be one of your biggest learning opportunities as you work at this level.
• A manager is accountable for the health and productivity of the team.
• Making the wrong person and manager is a mistake, but keeping her in that position once you’ve realized she’s wrong for it is a critical error.
• Don’t compromise on culture fit, especially when hiring managers. Many people are very reluctant to hire in management from outside, and for a good reason.
• Dedicate to 20% of your team schedule to “sustaining engineering”.

The big leagues

• It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers.
• VP is an engineering role, CTO is not.
• In my experience, most people need to hear something at least three times before it really sinks in.
• As a senior-most person in an organization, you’ll be watched closer than you ever been watched in your life.

Bootstrapping culture

• Structure is how we scale, diversify, and take on more complex long-term tasks. It’s more common in small companies to see structure come too late.
• He describes the early start-up as driving a race car. You’re close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you’re also at the risk of crashing at any moment, but you only take yourself down if you do. As you grow, you graduate to a commercial flight. You’re farther from the ground, and more people's lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly. Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.
• A complex system that works is invariably found to have evolved from a simple system that worked. Complex system design from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
• Culture is how things get done, without people having to think about it.
• Call them what you want pods or squads or pillars, but cross-functional product development groups are a popular structure for a good reason. By putting everyone who is needed to make a project successful together in one group, you help the members of those teams focus on the project at hand, and you make the communication for the whole group much more if active.
• Organizations that design systems, are constrained to produce the designs which are copies of the communication structures of these organizations.
• The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others.

TL;DR

In this short post I’ll tell you:

• how we implemented our fourth book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few key takeaways

You can read all about our other book clubs here:

• 1st - The Phoenix Project (has way more info on how we're doing it)
• 2nd - It doesn't have to be crazy at work
• 3rd - Pragmatic Programmer

⚠️ If you're thinking that there's no time to read the books, check this post on the math behind reading 30 books per year. If you think that this book club thing is cool, and you'd want to be a part of the group that's 'allowed' to read 'on the job', shoot me an email 👍

THE BOOK

This time we read the Stealing Fire: How Silicon Valley, the Navy SEALs, and Maverick Scientists Are Revolutionizing the Way We Live and Work.

Here are the Amazon and Goodreads ratings:

DATA POINTS

• avg(time to read) = 10 hours
• avg(liked the book) = 6.1 / 10
• avg(liked the book club) = 8.7 / 10

In general, we didn't quite like the book, and there was even a vote to stop and switch to another one. In the end, we persevered and thus such a high score for the book club itself.

KEY TAKEAWAYS

• We find the book interesting, but also really scary as it left us wondering what the 1% of 1% are doing to achieve the flow state
• A good part of what we’re habitually doing online is more to forget ourselves for a moment than inform ourselves for the long haul
• Time (and how to make the most of it) appears to be about five times more important to us than making love or money
• These days, we’re drowning in information, but starving for motivation.
• When a Harvard Medical School study confronted patients with lifestyle-related diseases that would kill them if they didn’t alter their behavior (type 2 diabetes, smoking, atherosclerosis, etc.), 87 percent couldn’t avoid this sentence. Turns out, we’d rather die than change.
• Eric Schmidt became Google’s CEO because he attended Burning Man
• We process more information when unconscious
• Surfing can get you in the flow state
• This book is like a commercial for drugs
• Eight weeks of meditation training measurably sharpened focus and cognition
• If coffee isn’t considered cheating, what makes smart drugs any different?
• Animals seek out drugs
• Slack prevents us from reaching (and staying in) the flow state
• It costs $25,000 to turn an average Joe into a combat-ready U.S. Marine.
• In 2014, EDM represented almost half of all concert sales, attracting a quarter of a million concertgoers at a time and drawing the attention of Wall Street investors and major private equity firms.
• Eight weeks of meditation training measurably sharpened focus and cognition
• Absolutely terrified knowing the final outcome of the Pied Piper story
• Stimulating the front part of the lobe causes visions of God

TL;DR

How about instead of just adding more new books to our read pile (and even more to the never-ending to-read pile), we revisit our list of the books that we've read and in 2020 we not just re-read them, but study them?

!TL;DR

Quotes are great

“The greatest satisfaction comes from mastering something that is truly difficult.”
~ Abraham Maslow

A positive fact

All of us are readers in this group, and we had to go through a lot of content to find the one that’s valuable. We can think of that as a process of getting the signal from the noise.

A sad fact

Even though we read a lot of books (and we may be looking into techniques to increase that number), we are not oblivious to the fact that there are just too many books and not enough time. Moreover so, we realize that after a certain amount of books that we've read in a certain category, the new ones are just not yielding the same ROI (I being the ever so slightly limited time). Most of them feel like they’re rehashing the ideas and are just geared toward the ‘current’ generation.

A little bit of math

Consider for a moment that we read 60 books per year (A lot, right? Well, here's the math behind reading 30 in a year). What if, in 2020, instead of just adding new books to the read pile, we set a goal only to read 30 (half of that, so adjust your math accordingly, please). But with a twist.

The twist and the ?

What if we revisit all the books that we’ve read in our career so far and commit to not only re-reading them in 2020, but actually studying them? So that we won’t just know ‘oh, yeah, I read that somewhere in the XYZ book,’ but instead we’ll have the actual book in RAM if you will (with UPS, of course). Sure, I’d reserve a slot for 10 new ones just in case 🙂

For added points, please proceed here

I’d love to hear what you think about the idea presented above 🙏. And also, I’d like to learn what were the signal vs. noise books in your career so far? To not make this into some long list, let’s cap it at five books.

So how about you, mister?

OK, OK, thought I’d get away with it 😎, here’s my entry:

• Leadership and self-deception
• Time management made simple
• How to win friends and influence people
• Think and grow rich
• Little prince

Conclusion

One thing is definite: our time. Let’s use it as effectively as possible by reading the books that bring the biggest bang for the buck.

Here are my notes from the practical book Scrum: The Art of Doing Twice the Work in Half the Time.

Several of us were reading it as a part of a 'smaller book club' and we all echoed the same feeling about the book: we love it and will not only look to apply it in the work environment but also at home in our personal lives.

Ingredients for scrum

• Product Owner
  • What and Why needs to be done
  • Knows the market, the customer and has a vision
• Team (3-9 people)
  • Decide on the Who and How
• Scrum Master
  • Coaches the Scrum framework and removes waste
• Create and prioritize the Backlog
  • Constantly evolving
• Refine and estimate the Backlog
  • Planning Poker with Fibonacci sequence
• Sprint planning
  • Team, Scrum Master, and the Product Owner
  • Always of fixed length (from 1 to 4 weeks in general)
  • Velocity
    • Sum of points done in one Sprint
  • Sprint goal
    • Everyone has to agree on one sprint goal in the Sprint
• Scrum board
  • Has lanes ToDo, Doing, Done (we use Clubhouse)
• Burndown chart
  • Chart showing a number of points done per day
• Daily Stand-up or Daily Scrum
  • 15 min max meeting where you answer three questions:
    • What did you do yesterday to help the team finish the Sprint?
    • What will you do today to help the team finish the Sprint?
    • Is there any obstacle blocking you or the team from achieving the Sprint goal?
• Sprint review or Sprint demo
  • Show what was done in a Sprint
    • Show what’s totally finished by the DoD (Definition of Done)
• Sprint retrospective
  • What went right?
  • What could have gone better?
  • What is the improvement in the process that we as a team can implement right away (in the next Sprint)?
  • The process should be blameless - we’re looking at the process, not people!

Takeaways per chapter

• CH #1 - The way the world works is broken
  • Planning is useful. Blindly following plans is stupid.
    • It's just too tempting to draw up endless charts. All the work needed to be done on the massive project laid out for everyone to see – but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas.
  • Inspect and adapt
    • Every little while, stop doing what you're doing, review what you've done, and see if it's still what you should be doing and if you can do it better.
  • Change or die
    • Clinging to the old way of doing things, of command and control and rigid predictability, will only bring failure. In the meantime, the competition that is willing to change will leave you in the dust.
  • Fail fast so you can fix early
    • Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness. Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort.
• CH #2 - the origins of Scrum
  • Hesitation is death
    • Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act!
  • Look outward for answers
    • Complex adaptive systems follow a few simple rules, which they learn from their environment.
  • Great teams are
    • They are cross-functional, autonomous, and empowered with a transcendent purpose.
  • Don't guess. Plan, Do, Check, Act.
    • Plan what you're going to do. Do it. Check whether it did what you wanted. Act on that and change how you're doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.
  • Shu Ha Ri
    • First, learn the rules and the forms, and once you've mastered them, making innovations. Finally, in a heightened state of mastery, discard the forms and just be – with all the learning internalized and decisions made almost unconsciously.
• CH #3 - Teams
  • Pull the right lever
    • Change team performance. That has much more impact – by several orders of magnitude – than individual performance.
  • Transcendence
    • Great teams have a purpose that is greater than the individual; e.g. burying General MacArthur, winning the NBA championship.
  • Autonomy
    • Give teams the freedom to make decisions on how to take action – to be respected as masters of their craft. The ability to improvise will make all the difference, whether the unit is reporting on a revolution in the Middle East or making the sale.
  • Cross-functional
    • The team must have every skill needed to complete a project, whether the mission is to deliver Salesforce.com software or capture terrorists in Iraq.
  • Small Wins
    • Small teams get work done faster than big teams. The rule of thumb is 7 members ± 2. Err on the small side.
  • Blame is stupid
    • Don't look for bad people; look for bad systems – one that incentivizes bad behavior and rewards poor performance.
• CH #4 - Time
  • Time is finite. Treat it that way.
    • Break down your work into what can be accomplished in a regular, set, short period - optimally 1 to 4 weeks. And if you've caught the Scrum fever, call at the Sprint.
  • Demo or die
    • At the end of each sprint, have something that it's done – something that can be used (to fly, drive, whatever)
  • Throw away your business cards
    • Titles are specialized status markers. Be known for what you do, not how you're referred to.
  • Everyone knows everything
    • Communication saturation accelerates work.
  • One meeting a day
    • When it comes to team check-ins, once a day is enough. Get together for 15 minutes at the daily standup, see what can be done to increase speed, and do it.
• CH #5 - Waste is a crime
  • Multitasking makes you stupid
    • Doing more than one thing at a time makes you slower and worse at both tasks. Don't do it. If you think this doesn't apply to you, you're wrong – it does.
  • Half-done is not done
    • A half-built car simply ties up resources that could be used to create value or save money. Anything that's "in process" costs money and energy without delivering anything.
  • Do it right the first time
    • When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than 20 times longer than if you fix it now.
  • Working too hard only makes more work
    • Working long hours doesn't get more done; it gets less done. Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Rather than work late or on weekends, work weekdays only at a sustainable pace. And take a vacation.
  • Don't be unreasonable
    • Goals that are challenging our motivators; goals that are impossible are just depressing.
  • No heroics
    • If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.
  • Enough with the stupid policies
    • Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just that – stupid. If your office seems like a Dilbert cartoon, fix it.
  • No assholes
    • Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.
  • Strive for flow
    • Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible.
• CH #6 - Plan reality, not fantasy
  • The map is not the terrain
    • Don't fall in love with your plan. It's almost certainly wrong.
  • Only plan what you need to do
    • Don't try to project everything else years in advance. Just plan enough to keep your teams busy.
  • What kind of dog is it?
    • Don't estimate in absolute terms like hours – it's been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size, or, more commonly, the Fibonacci sequence.
  • Ask the Oracle
    • Use a blank technique, like the Delphi method, to avoid anchoring biases such as the halo effect or bandwagon effect or just plain stupid groupthink.
  • Planing poker
    • Use planning poker to quickly estimate the work that needs to be done.
  • Work is a story
    • Think first about who will be getting value from something, then about what it is, and then why do you need it. Humans think in narratives, so give them one. As an X, I want Y, so that Z.
  • Know your velocity
    • Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.
  • Velocity x Time = Delivery
    • Once you know how fast you're going, you'll know how soon you'll get there.
  • Set audacious goals
    • With Scrum it is not that hard to double production or cut on delivery time in half. If you do it the right way, your revenue and stock price should double as well.
• CH #7 - Happiness
  • It's the journey, not the destination
    • True happiness is found in the process, not the result. often we only reward the results, but what we are really want to reward his people striving towards greatness.
  • Happy is the new black
    • It helps you make smarter decisions. Plus, when you're happy, you're more creative, less likely to leave your job, and more likely to accomplish far more than you've ever anticipated.
  • Quantify happiness
    • It's not enough to just feel good; you need to measure that feeling and compare it to actual performance. Other metrics look backward. Happiness is the future-looking metric.
  • Get better every day - and measure it
    • At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they'll accomplish in the next Sprint.
  • Secrecy is poison
    • Nothing should be secret. Everyone should know everything, and that includes salaries and financials. Obfuscation only serves people who serve themselves.
  • Make work visible
    • Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done. Everyone should see it, and everyone should update it every day.
  • Happiness is autonomy, mastery, and purpose
    • Everyone wants to control their own destiny, and get better at what they do, and serve a purpose greater than themselves.
  • Pop the happy bubble
    • Don't get so happy that you start believing your own bullshit. Make sure happiness is measured against performance and if there is a disconnect, be prepared to act. Complacency is the enemy of success.
• CH #8 - Priorities
  • Make a list. Check it twice.
    • Create a list of everything that could possibly be done on the project. Then prioritize it. Put the items with the highest value and lowest risk at the top of the backlog, then the next, and then the next.
  • The Product owner
    • She translates vision into Backlog. She needs to understand the business case, the market, and the customer.
    • Has knowledge of the domain and the power to make final decisions. Is available to answer questions and is accountable for delivering value.
  • A leader isn't a boss
    • A product owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team.
  • Observe, Orient, Decide, Act (OODA)
    • See the whole strategic picture, but act tactically and quickly
  • Fear, uncertainty, and doubt
    • It's better to give than to receive. Get inside your competitors OODA loop and wrap them up in their own confusion.
  • Get your money for nothing and your change for free
    • Create new things as long as those new things deliver value all stop be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.
• CH #9 - Change the world
  • Scrum accelerates all human endeavors
    • The type of project or problem doesn't matter – Scrum can be used in any endeavor to improve performance and results
  • Scrum for schools
    • In the Netherlands, a growing number of teachers are using Scrum to teach high school. They see an almost immediate improvement in test scores of more than 10%. And they're engaging all sorts a few students, from vocational to gifted.
  • Scrum for poverty
    • In Uganda, the Grameen Foundation is using Scrum to deliver agricultural and market data to poor rural farmers. The result: double the yield and double the revenue for some of the poorest people on the planet.
  • Rip up your business cards
    • Get rid of old titles, all managers, all structures. Give people the freedom to do what they think best and the responsibility to be accountable for it. You'll be surprised at the results.

TL;DR

In this short post I’ll tell you:

• how we implemented our third book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few quotes that we liked

You can read all about our other book clubs here:

• 1st - The Phoenix Project (has way more info on how we're doing it)
• 2nd - It doesn't have to be crazy at work

⚠️ If you're thinking that there's no time to read the books, check this post on the math behind reading 30 books per year.  If you think book club thing is cool, and you'd want to be a part of the group that's 'allowed' to read 'on the job', shoot me an email ?

THE BOOK

• This time we read the Pragmatic Programmer

DATA POINTS

• avg(time to read) = 6 hours
• avg(liked the book) = 6.9 / 10
• avg(liked the book club) = 8.8 / 10

KEY TAKEAWAYS

• Quality is a team issue - the team as a whole should not tolerate broken windows

• Treat the documentation the same way you treat your code

• Prototypes are disposable and shouldn't go into production

• Crashing early makes life a lot easier when debugging code

• Decoupling is good, but as a group, we don't subscribe to the idea that your software needs to be so flexible that swapping out databases would just be as easy as changing a line of code

• Shell is way more powerful than GUI

• Don't be a slave to old code, always be ready to refactor

• Don't refactor and change functionality at the same time

• Take the time to spell out connectionPool instead of cp

• Treat code as gardening

• "Why" is more important than the "what" - don't blindly duplicate existing workflow when translating into code from manual processes

• Try not to be a slave to the methodology

• Overengineering is as bad as under-engineering

• Premature optimization is bad

• Making a project glossary to save time later on looking for acronym translations is a good idea

• The code should have comments, but too many comments can be just as bad as too few

• Attaching codenames to new projects/features is cool

• Tailoring your message to the audience is an important skill to have

• Don't tell your boss that it's done until it's tested

• Finding bugs early in the process saves money in the long run

• Learn a new language every year, and read a tech book every month and read non-tech books as well

• The word deadline comes from a line in prisons which if crossed by prisoners they'd get shot

• The book is mostly a refresher of techniques/ideas that we already know - new book coming out for 20th anniversary

Here are my notes from a very practical book The Coaching Habit by Michael Bungay Stanier:

The book covers 7 questions:

• Kickstart: What's on your mind
• AWE: And what else?
• Focus: What's the real challenge here for you?
• Foundation: What do you want?
• Lazy: How can I help?
• Strategic: If you're saying yes to this, what are you saying no to?

• Learning: What was most useful for you?

• The essence of coaching lies in helping others and unlocking their potential

• If you need to have a lead in phrase, consider using: 'out of curiosity'
• Three vicious circles that plague our workplaces: overdependence, getting overwhelmed, and becoming disconnected.
• Ask people more questions and give less advice
• 45% of our waking behavior is habitual
• If you spend too much time imagining the outcome, you're less motivated to actually do the work to get there.
• Think less about what your habits can do for you, and more about how this new habit will help the person or people you care about.
• Charles Duhigg says that there are just five types of triggers: location, time, and emotional state, other people, and immediately preceding action.
• I will ask just one question and then be quiet while I wait for the answer.
• Coaching for performance is about addressing and fixing a specific problem or challenge. Coaching for development is about turning the focus from the issue to the person dealing with the issue, the person who's managing the fire.
• 3P's: people, projects, patterns
• The brain accounts for only 2% of the body weight, but it uses about 20% of the energy
• The first answer someone gives you is rarely the only answer, and it's rarely the best answer.
• The brain counts like this: one, two, three, four...lots.
• Stop offering up advice with a question mark attached. That doesn't count as asking the question. If you've got an idea, wait. Ask, "And, what else?", and you'll often find that the person comes up with the very same idea that's burning a hole in your brain.
• The simple act of adding 'for you today' to the end of as many questions as possible is an everyday technique for making conversations more development than performance oriented.
• Stick to the question starting with "What" and avoid questions starting with "Why".
  • Why did you do that? => What were you hoping for here?
  • Why did you think this was a good idea? => What made you choose this course of action?
  • Why are you bothering with this => What's important for you here?
• The single biggest problem with communication is the illusion that it has taken place. ~ G.B. Shaw
• 9 universal needs based on Marshall Rosenberg: affection, creation, recreation, freedom, identity, understanding, participation, protection, subsistence
• Five times a second, at an unconscious level, your brain is scanning the environment around you and asking itself: it's safe here, or is it dangerous?
• After asking a question, just patiently wait for an answer.
• Based on Karpman, there are three archetypal roles: victim, persecutor, and rescuer
• While talking nod your head, make encouragement noises and maintain
• Being busy is no measure of success
• The essence of strategy is choosing what not to do. ~ Michael Porter
• Acknowledge the reply of a person by saying, "Yes, that's good", instead of just going into another question.
• People don't really learn when you tell them something. They don't even really learn when they do something. They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened.
• This is why, in a nutshell, the advice is overrated. I can tell you something, and it's got the limited chance of making its way into your brain's hippocampus, the region that encodes memory. If I can ask you a question and you generate the answer yourself, the odds increase substantially.x
• What have you learned since we last met?
• So, what was most useful here for you? What did you find most valuable about this chat? What worked best here?
• Finish on a high note, and you make everything that went before it look better.
• "Before I jump into a longer reply, let me ask you: What's the real challenge here for you?

TL;DR

You can read all about how we implemented our 1st book club idea in our engineering team, and in this post, I'm going to do the same but with a new book. In this short post I'll tell you:

• how we implemented the second book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few learnings, comments and (as I usually do in my book posts) quotes

What book did we read?

We read the book called It Doesn't Have to Be Crazy at Work by Jason Fried and David Heinemeier Hansson.

It seems that the Goodreads and Amazon reviewers liked the book.

However, I’m not really sure why, because this is how much we liked (or better said didn’t) the book. So, 4.5/10 with a max rating of 6 says a lot.

How did we do it?

We read it in only three weeks which means it was a really easy read. This comes down to about 75 pages per week, which amounts to 15 pages per work day.

On average, it took us 2hr and 22 minutes to finish the book, or about 9 minutes per work day.

Here's a short post on the math behind reading 30 books per year in case you're interested.

What did we like?

Even though we didn’t like the book in general, it still had some parts that we liked:

• Office hours idea
• Stance towards interviews - and paying for spec work
• Company is not a family
• Salary negotiation is crap
• Calm goodbyes
• Fridays off during summer

What we didn't like

A lot of the chapters were common sense, and we agreed with them (few mentioned above), but some of the things we just couldn't agree with:

• No goal setting
• Not going out of your comfort zone - promoting mediocrity
• It seems like the whole book is an advertisement for them
• They support multiple versions
• This most probably won’t work for a bigger company

Some quotes

As usual in my book posts, here are some quotes that we liked:

• We don't mind leaving some money on the table, and we don't need to squeeze every drop out of the lemon. Those final drops usually taste sour, anyway.
• There is nothing so useless as doing efficiently that which should not be done at all.
• Your company is a product. If you want to make the product better, you have to keep tweaking, revising, and iterating.

• Comparison is the death of joy.

Conclusion

Even though we didn't like the book in general, it definitely wasn't a total waste of time. We already started with the next book (Pragmatic Programmer), and this time we hope the book to be better.

A question for those that already conducted book clubs in your engineering organizations - what books did you read?

Here are my favorite quotes from the book Way of the Warrior Kid: From Wimpy to Warrior the Navy SEAL Way: A Novel by Jocko Willink:

If you need rest, you go to sleep earlier. You don't sleep in, and you don't miss workouts. Even if you can't perform at a high-level, showing up and doing something is still a thousand times better than not showing up at all.

The most important part of discipline is following rules that you set for yourself. It is doing things you might not always feel like doing – things that make you better.

I don't worry about motivation, because motivation comes and goes. It's just a feeling. You might feel motivated to do something, and you might not. The thing that keeps you on course and keeps you on the warrior path isn't motivation. It is discipline. Discipline gets you out of bed. Discipline gets you onto the pull-up bar. Discipline gets you to grind it out in the jiu-jitsu class.

We don't quit. Ever.

Fear is normal. In fact, fear is good. Fear is what warns you when things are dangerous. Fear is what makes you prepare. Fear keeps us out of a lot of trouble. So there is nothing wrong with fear. But fear can also be overwhelming. It can be unreasonable. It can cause you to freeze up and make bad decisions or hesitate when you need to act. So you have to learn to control fear. And that's what you need to do right now.

The fear is in the waiting. Once you have prepared, trained, studied and planned, there is only one thing left to do: go.

You know the path. And you are humble. That is the most important thing about being a leader.

Here are my favorite quotes from the book Peak: Secrets from the New Science of Expertise by K. Anders Ericsson.

You have to keep upping the ante: run farther, run faster, run uphill. If you don’t keep pushing and pushing and pushing some more, the body will settle into homeostasis, albeit at a different level than before, and you will stop improving.

The best way to get past any barrier is to come at it from a different direction, which is one reason it is useful to work with a teacher or coach. Even the most motivated and intelligent student will advance more quickly under the tutelage of someone who knows the best order in which to learn things, who understands and can demonstrate the proper way to perform various skills, who can provide useful feedback, and who can devise practice activities designed to overcome particular weaknesses.

You seldom improve much without giving the task your full attention.

Deliberate practice involves well-defined, specific goals and often involves improving some aspect of the target performance; it is not aimed at some vague overall improvement. Once an overall goal has been set, a teacher or coach will develop a plan for making a series of small changes that will add up to the desired larger change. Improving some aspect of the target performance allows a performer to see that his or her performances have been improved by the training. Deliberate practice is deliberate, that is, it requires a person’s full attention and conscious actions. It isn’t enough to simply follow a teacher’s or coach’s directions. The student must concentrate on the specific goal for his or her practice activity so that adjustments can be made to control practice.

You don’t build mental representations by thinking about something; you build them by trying to do something, failing, revising, and trying again, over and over. When you’re done, not only have you developed an effective mental representation for the skill you were developing, but you have also absorbed a great deal of information connected with that skill.