Download Slides PDF or read more
It is available online.
Shortly after I finished Inspired book Shape Up book came to my radar. After reading this book the whole puzzle got together. The pieces:
This book serves well as a guide on how to use Basecamp. The closer your process is to this book, the more useful Basecamp will be for you.
It’s important to note that Basecamp is a cash-cow. The quality of the development process is not necessary affects its success. Read the book with a grain of salt.
Their process is also Dual Track. The first stage is exploration and the second is development. However unlike in Inspired, it’s not clear if they ever do user testing. The book is very practical and it’s easy to see that it evolved over time.
I find Shape Up process very reactive as they discourage having backlog. I agree with the principle that important ideas will always come back, so you don’t need to record them. However they went to the extreme to reinvent the road map every 2 months. Basecamp doesn’t feel like a product but a playground for its founders.
I think the book will gain popularity because it’s short and free. It would serve as a good introduction to dual track processes. I will recommended it on this basis to others.
My friend is a big fan of Marty Cagan. He is so impressed by his work that it made me think I’m missing out, so I’ve decided to read it. Inspired is a book for product managers about product managers by product managers.
Let’s start with important things first. I loved it. My career is a decade old and I was surprised how little I knew about product development. This book taught me a lot. What product managers are, what they are not, what they do, how to hire and how to work with them. It’s probably the most comprehensive book on a single topic.
The mind blowing discovery for my was at the end. The author is highlighting through the book about the difference between normal agile coach and the one who worked in product team. It’s only at the end of the book he explains the difference. Scrum as the most popular agile methodology is created in consulting (custom software in the book). It works amazingly well in such setup and it is completely unsuitable for product teams. I knew it myself deep inside, but verbalising it made it real. I like agile manifesto. With that the new knowledge 12 principles behind the Agile Manifesto opened up from a completely new perspective.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It’s great for consultants, pointless for product teams.
The process the author proposes is something between waterfall and agile. In short you don’t develop anything until you’ve proven the prototype and business model. I was very skeptical at the start but finally got convinced that it is a good process to use. The book does not give it a name, but people call it Dual Track Development.
On the first track you explore ideas, come up with prototypes and test them on users. The idea is to keep the feedback loop tight and iterate on ideas. On this track all roles must be involved, including developers. That avoid the problem with waterfall model where levels don’t communicate.
The second track is usual development process. That could be Scrum, Kanban or chaos driven development.
Both tracks run in parallel, but with different cycles.
If you test an idea and it fails, you just scrap it and move to the next. The BIG difference to plain agile you don’t pollute your code base with bad ideas. Also when you start development you already have well designed, tested and proven feature. No more assumptions and no more pivoting.
Even though the book is mostly for product managers, I found it very useful, so would recommend it to everybody who is in software development.
This is a second time I listened this book. It wasn't a standard audiobook, but audio theatre with multiple voices and sound effects.
I enjoyed it like the first time, but also picked up the bits that I missed before. That allowed me to enjoy the book even more.
I better understood the characters and the love narrative. My original critic is only partially relevant now. Turns out I didn't get it the first time.
This time I spent more time researching the Objectivism, which is the main philosophy in the book. I found that hard to navigate and differentiate philosophical terms. It's like learning chemical elements without periodic table. Would be great to get some framework for different philosophies.
I love the title of this book, it can't be said better. The book was release in 1987 and had its third edition in 2013. The content is still relevant to this day, but sometimes it feels dated.
This is a great book, but I'd say hold off from reading it until you get into managing people. Then this book becomes invaluable resource. It describes the work dynamics from the social perspective and even touches on a big topic like happiness in life.
The book confirmed and cleared a lot of my observations. My three highlights:
Software quality is a cult. Not striving for the best is the common mistakes most companies do. It's not just cutting corners but has an enormous phycological consequences. One of them is job satisfaction. By pushing dev speed over quality you rip the most important part for developers, to be proud of the craft. You might say the speed to market is the king. Sure, but don't be surprised when developers resign.
Hidden hiring costs. It's not so hidden, just ignored. Based on my estimates it costs 50k to hire new candidate. The average employment duration is 2 years. It means you pay 25k per year per hire. It's ironic when company wants to save 5k and not to match the salary offer of the resigning candidate. People overvalue simple numbers and ignore more complex ones. The short story value your people while you have them, otherwise you will pay for it. Even if you spend 20k in perks per employee per year, you should celebrate your decision. It made your employee happier and you saved 5k.
I also enjoyed the chapter on introducing change to organisations. I was burnt in the past when I wanted to improve things. I leant the lesson: people really hate to change. The chapter shows a technique to ease the transformation. Each change needs a catalyst. You need to show and convince the people that the status quo is wrong. The catalyst should create the chaos, the bigger — the better. Only after the people are scared enough you can introduce your idea as a solution to the chaos.
The book sounds too good to be true, but I like the reasoning. I wish it had more to back it up, to build my confidence in the content. But as mentioned above, this book is highly recommended.
I'm pretty good with money (at least I'd like to think that). However I lack a lot of common knowledge about Australian rules. For example how super works or what happens when your bank goes bankrupt. This book is mostly relevant to only Australians, as financial system differs in each country.
The book present a simple step by step guide on how to take your financial life under control. Starting from the bottom of owning a lot of debt up to getting the financial independence. This book is recent which is important as the content is time relevant.
The books proves a good general knowledge and a must read for all Australians.
Great book! It talks about tribe (group of people) culture. It's mostly described in the context of work organizations. The book is inline with my own experience. I saw it as the explanation of the things I didn't see at the time.
The content is very well structured and to the point. It has a good balance between stories and actionable steps.
You can download free audiobook. You'll need to go through 5 pages to get the file, but it's worth it.
If you've achieved competence in your career, this book is a must read for you.
I will read the book the second time to better understand it. One audiobook wasn't enough to fully appreciate the insights.
I do not recommend this book. The book brags about success stories. If at least one employee heard of OKRs, the author would claim the company's success solely to OKRs. This book takes survivorship bias to the extreme. What this book does not talk is how the mentioned companies, including OKR mother-ship Google, constantly fail. You might assume those teams didn't implement OKRs correctly. However the book does not tell you the correct way and you have to figure out it for yourself.
Without that, it's a pigeon superstition:
However I would recommend the resources at the end of the book.
Don't get me wrong, the topic of goal setting and uniting teams is very important. OKR is a fancy word for the goal setting and it creates more confusion. Without understanding of OKR implementation details it's too easy to fall into cargo culting.
It's a weak book. The author's style of writing doesn't help either. The continuity breaks, thoughts jump and the lack of structure make it hard to build the understanding.
There are few good quotes and thoughts, but unless you are into group psychology, don't waste your time. The only reason to read this book is for completeness on the topic and to see the different perspectives.
Recently I've started using external 4K monitor with my Macbook Pro. I was shocked to discover that the laptop is running 30% slower. That's right it's slower by third.
I've got one of the most powerful Macbooks you could buy at 2018 with i9 processor (2.9GHz with 6 Cores), 32GB RAM and Radeon Pro 560X. However that does not matter because the power is throttled. You might remember the throttling story when the laptop was released. It is almost the same now after the fix.
For example, my test suite takes 1m40s to run without external monitor. However with the external monitor it takes 2m10s. That's a big jump.
That's a last book for the year. It's very short and has a very clear message. The title says it all. I love it a lot. However I'm biased as my opinion is inline with the book.
I've discovered that the book splits people into two opposite sides. The question is simple, so I've found everybody have an answer for it. Do you think you should be the best in what you do? I would recommend this book, does not matter what your answer is. It's worth 1-2 hours reading.
I'm a big believer in habits and picked this book specifically for this reason. The book has three parts: individuals, organizations and society.
The individuals part is the best. It explains the habits in a structured form. There are a lot of insights and knowledge that you can apply yourself.
In the second part that the book starts to go down hill and it goes fast. There a lot of interesting stories, but no analysis. It is the same problem as Charles' another book Smarter Faster Better, which I've read few months earlier. Entertaining to read - useless in building understanding. Most stories have too many unnecessary details. Chapters are hard to relate among themselves and the book lacks purpose. It's very disappointing, but fun at the same time.
"Habit" is a big word for this book, which it does not deserve. More accurate name would be "Stories about influencing people".
I would recommend to read the first part about individuals. You can skip or skim the rest.
UV index is very harsh in Australia. While 11 index is considered Extreme, it's often you'll see 13 in Melbourne. Thus I bought a beach tent.
I checked all of the available resources on how to set it up and still miserably failed to do it myself. It's almost always windy on the beach. During the setup the tent cover becomes a huge wind sail and it's a challenge to secure it with ropes before it flies away.
As a result I came up with new way to set it up.
That's my beach book and it's a great fit. Short aphorisms are quick to read and give you a lot of opportunity to think about them. I didn't understand the half of the aphorisms, which gives a reason to read the book again.
I've found this book very insightful. It talks about modeling the application based on domain or real business terms and operations. My development experience slowly led me to the same conclusion. DDD is very valuable technique and it should be more talked in the software industry.
I can't remember seeing the DDD concept in the book yet. While the book's content is great, the delivery is horrible. I found it to have a bad flow, being too long and slow at times and often confusing. The more appropriate title would be "DDD Half-Distilled". I feel the content could be cut in half without significant drop in value.
I've picked this book for the second book club meeting. It is short and publicly available. The book provides interesting insight into the company, which is successfully operating with flat structure for 20 years. It's so different so it's hard to believe it.
The most surprising part for me was about hiring as it is considered the most important task in the company. I agree with such approach, but unfortunately it's not so common.
Few other things I've liked: T-shape people, peer reviews, cabals, stack ranking and compensation.
The book gives a good overview of the culture. I really want to know more details how everything is setup. That's where the real insight.
RubyWeekly is a weekly email with curated list of links about Ruby. It might take me few hours to read through it if the content is interesting. It’s hard to find 2 hours of focus time. It would be nice if I could track each link in the newsletter separately.
This blog post describes my evolving solution and how you can optimise your workflow and read RubyWeekly with one click.
Great books and great methodology. It would be even better if the author didn’t oversell it. The way he presents it, is like he treated all diseases on the planet. After a while of such praising of his work you start to question his credibility.
The author made a good point. You can't significantly change the performance of a person in a short time. However you can significantly affect the team. Everything should be seen as a system. People are just the participants in the game.
There are no bad people, but bad systems
The book made me think of Nazism. Its success can be explained by the system that was in place. Most german people didn't want to kill anyone on the individual level. However they played their cog role in the complex Nazism machine.
Anyway, back to the book. Scrum is focused on providing the basic rules for the process in the team. It prioritises efficiency, uncertainty and change. I can't think how those rules could be distilled even more. That make me think the scrum would be around for a long time.
I would recommend this book to everybody. But don’t be put off by the writer. The product does not change because of the bad salesperson.
This was an audiobook, and I did an experiment with it. I’ve listened to this book three times in a row. The goal was to see how the second and the third rounds would be different.
After the first round, I liked the book. Each point is backed by real life example. That makes the listening a joy.
The second round wasn’t much different. I’ve picked up some missed details. However overall understanding of the book is only improved by 10%.
For the last round I created a mind map while listening to it. To my surprise that made a huge difference. The mind map forced me to become an active listener. The overall understanding doubled. That shocked me because that was the third time I’ve listened to it.
My favourite part is about goal setting. There are ‘smart goals’ and ‘stretch goals’. Smart goals are achievable and measurable. These are your everyday goals. They prioritise efficiency of what you are already doing. In contrast stretch goals are about the direction.
To better understand them, think of the running analogy. Smart - is how fast you are running. Stretch - is where you are running to.
While the book has a great content, it feels disjointed. It would be nice to combine all knowledge into a recipe to follow. I guess it’s up to the reader to do so.
Yet another interesting book from Dan Ariely about behavioural psychology. The book talks what motivates us at work. It feels that book heavily overlaps with author's other books. It's good to remind about those things anyway.
I decided to read some Russian classics. The book is about people and society. The book dates to the 19th century. However, it is still relevant today. The social aspect of the society did not evolve as quickly as the technology.
Selecting good communication and collaboration tools for work, is just like having a solid foundation for the house: if it’s flawed then you can’t avoid the cracks in the walls.
Often it’s our ignorance of communication theory that caused all of that.
The article will give you a model which will help you understand why new tools don’t fit into your company and why existing tools are abused in their usage. I will describe the five main categories of collaboration and communication tools and explain their purpose and needs along with the tool examples.
Let’s start with something popular.
Crucial Conversations is a very practical book. You can apply knowledge in everyday life straight after reading it. As you probably know our life is not always vanilla. Quite often we need to deal with people who completely disagree with our opinion. Whether it be your boss, partner, neighbour or co-worker. This book teaches you how to have those conversations without alienating the relationship. The book is very insightful and I feel I need to read it again to better understand it.
I definitely recommend the book for everybody and I wish everybody to have a read of it.
It’s loooooong, very long, 30+ hours long. I can’t count the number of times I thought to stop listening to it but somehow I managed to finish it.
Such level of details is acceptable at court when creating a criminal record. Let me ask you, would you be interesting in reading the criminal records? Nobody cares who said what, to who and at what minute. The readers want a story, a good story with overview of what’s happening. Unfortunately this book pollutes a good story with unnecessary details.
One advice to you is to listen to this audiobook on x1.5 speed, I started with x1.25, and it wasn’t fast enough. You get bored faster than your patience for the author’s mumbles.
First of all, great book and now the details. I thought it was a book about biology and how humans evolved from monkeys. It definitely has a lot of it, but that’s only a small portion of the book.
While I was reading it I realised the book 100% proves its title. Think about some time in year 3000 or perhaps when aliens colonise the earth. They would want to study the creatures which were living on the planet. I think this book speaks about us more than anything. The author manages to distance himself and you truly think it’s just another history book.
It is a pretty long book, at times it could be boring because of the details, but only sometimes. This is one of the best book I’ve read and I definitely would read it again.
I wrote a small Rails app, which sends emails on a particular schedule. For example to send an email every week on monday and thursday at 7:00am Melbourne time.
However Heroku doesn’t have cron or good free alternative. I wrote a cron replacement in 5 minutes. This post shows how I did it. There are three parts:
The story starts with the RubyWeekly newsletter. Once signed up, every week you’ll receive a collection of curated links. It’s a great resource to learn Ruby. It could take a few hours to read through the interesting articles.
I found it hard to set aside 2-4 hours every week to read them in one go. So I wrote a script parses each week’s issue into an RSS feed. The feed had one item per link, which gave more granular control.
This book is very hyped this year. To summarise it's a detailed refactoring tutorial. It could also be called "Refactoring 1-on-1 for dummies".
I like that it goes through long and tedious process of proper TDD. I don't like for the exactly same reason and had to skim through it. People who are not familiar with TDD should find it very useful.
The book was a good detailed reminder of the refactoring process for me. However I wouldn't recommend it to myself.
Update 1: The article was translated to Japanese
Update 2: This post is featured in RubyWeekly #374
&. operator, added to Ruby 2.3, is handy and I’ve cleaned a lot of code with it. You can use it in conjunction with default operators as described in Ruby's New &.!= Operator.
Recently I introduced a bug when using
&.. First we had:
if start_date && start_date < start_of_month && end_date.nil? # … end
Unfortunately this presentation had a lot of transition and my recording failed, so please have a look at the transitions in video slides below.
A quick read which I would recommend to every mid rails developer and higher. It's common for developers to outgrow their tools. Rather than learn new skills, people start to blame the tools. Your heard those people: "Rails does not scale", "ActiveRecord is antipattern" etc. The books show few patterns which allow to build big Rails application with only small changes to standard 'Rails way'.
The book recommends active_type gem. I would recommend other gem active_interaction instead. active_interaction gem is more superior in my opinion and I've successfully used it in multiple projects over the last 2 years.
As for the CSS structuring, BEM is definitely a good choice to get control over your styles. Only issue with it, if not enforced it loosed its value, so every developer should be very diciplined to follow BEM.
There is only 1 option which is better than BEM, it's css modules. I only used it with ember.js, not Rails though. It automates steps that you have to do with BEM. However css modules require deep integration into the tools you use, which makes it harder to bring into the project.
The book talks about the process of running a 5 day long test to validate your idea/product. You might have an idea to start new business or how to engage your existing customers, whatever it is you should do as quickly as possible and as effectively as possible.
The book provides a very detailed step by step guide how to run the full spring as well as explains why things are done the certain way.
While books tries to prove itself with examples from big or popular companies, it feel a bit cheap because success of the company doesn't depend on the success of the product. It's way more complex than that.
I'll be very interested to try it on practice. In theory it should work very well.
This quick and easy to read book I would recommend to every developer. It talks about all the little things which are often neglected and what developers deal with every day. Naming methods and variables, extracting business logic, code comments, aesthetics and code readability.
This knowledge is language agnostic and the best mastered over reading lots of code, or reading this book :)
That was a lucky pick to read after "The Brain's Way of Healing". That book talks about unconscious part of the brain. It does make a lot of sense and I've drew a lot of parallels with the "The Flow" book. To put it simply, we are animals and millions years of evolution didn't disappear when we've got consciousness.
When we are leaning something we actually teaching our unconscious part of the brain, while consciousness is there to guide that learning process.
Conscious and unconscious, this is just a theory to explain our body, and probably not very accurate. But it is enough to start benefit from it. That book shows how little we know about ourselves.