Author: Nir Eyal Subtitle: How to Control Your Attention and Choose Your Life
TLDR; Being indistractable is a superpower of people leaving happy lives according to their own values and beliefs. In his book, Nir Eyal gives everything you need to understand and gain that power to change your own life for the better.
Nir worked in the video gaming and advertising industries where he learned and applied the techniques used to motivate and manipulate users. He writes to help companies create behaviors that benefit their users while educating people on how to build healthful habits in their own lives.
For whom?
This book is for anybody, who wants to live their own life, aligned with own values and driven by conscious choices.
How to read
Nir was kind enough and gave precise recommendation on this, so I have nothing to add there.
You’re welcome to navigate the four steps to becoming indistractable however you like, but I recommend you proceed in order through parts one to four.
That’s what I did, and have zero regrets. However, if you don’t like to read books in order or prefer learning by examples, Nir covered you as well:
If you’re the kind of person who likes to learn by exmpalpe, and you want to see these tactics in action first, feel free to read parts fine and on, then come back through the first four parts for a deeper explanation.
My impression
I was impressed by the amount of great reviews at the beginning of the book. There are several pages of them, but I was already hooked by reading the first several reviews.
The book is very well-structured and easy to follow. Relatively short chapters allow getting joy from the book step by step. It’s nice that each chapter ends with Remember this section holding the major ideas, so it will be easy to quickly refresh some key points in memory. In addition to that, there is a Chapter Takeaways section at the end of the book for a supersonic look back.
Language used in the book is of high quality, in my opinion, it is very expressive and precise. I’m not a native speaker and had to use a translator from time to time to get more accurate meaning of some words, which is good for me as I learned some new words phrases.
I liked a lot the model of traction and distraction presented in the book, and was surprised that modern tech is not the source of the distraction problem, but human brain is. It was also interesting to read how brain structures and behaviors which helped us to survive over the ages are preventing us from feeling comfort for too long.
Furthermore, there are enough tips on how to explore distractions, deal with internal and external triggers, and stay focused on what really matters. Ideas and tools mentioned in the book look simple and obvious (after you read them), yet insightful at the same time. It’s easy to try them out, and I’ve already started validating them on practice. Don’t have enough results to share yet, but I’m very excited at the moment and curious where I will get to in the next months.
Favorite quotes
Sharing my favorite quotes as is, and letting you make your own conclusions.
Living the life we want requires not only doing the right things; it also requires we stop doing the wrong things that take us off track.
It’s good to know that feeling bad isn’t actually bad; it’s exactly what survival of the fittest intended.
While we can’t control the feelings and thoughts that pop into our heads, we can control what we do with them.
you are only powerless if you think you are.
Think of all the locks, security systems, and storage units we use to protect our property and how little we do to protect our time.
You can’t call something a distraction unless you know what it’s distracting you from.
Staying late at work or feeling pressured to reply to work-related messages after hours means spending less time with our family and friends or doing something for ourselves.
This review is barely a tip of the iceberg. I encourage you getting the book (FYI, I’m not affiliated), reading it from cover to cover, and becoming the main stakeholder in your life!
“Now” – the magic moment in time which will never happen twice in your life. It’s shared by billions of people on Earth but still unique for every individual. In this post, I want to capture my very own “now” and share it with you. It’s all about me and my life, so proceed reading if you are interested in day-to-day details. As always, it’s ok to skip if you are not at that place now.
I’ve heard about the idea of “now” page from my blogging group fellows and liked it a lot but was putting aside for a while to focus on writing about leadership, software development and books. I’m at the end of the year and sort of trying to slow down a bit after a long, challenging and eventful year. That in my opinion makes a good timing for “now” post. So where I am now?
I am at my home now (the rented apartment at the northern part of Moscow), in my office (cozy corner in the living room), writing in the dark room (it’s less than 5pm, but already dark).
The Christmas tree is all set up and lights are blinking to remind about the upcoming New Year. There are still three days of work left before the holidays, but the holiday mood is already there. I probably need to explain a bit the context specific for Russia and some other countries. Christmas is celebrated on Jan 7th, that’s why I’m not away from keyboard yet as most of my colleagues, and New Year’s Eve kicks-off a holiday season with big presents exchange happening on the New Year night.
That Christmas/New Year mood though has a bittersweet flavor this time. My daughter has got sick couple of days ago and there is not that much emotional energy left to party and celebrate. Anyway, I’m looking forward to it as a very needed break to refill my tank and jump into exciting 2022. There is still enough time for my kid to recover and for us to get prepared for a little family party.
My wife and I had a very productive year, learned a lot and have enough moments to remember. We both miss trips, but 2022 looks more promising in that regard, despite all the additional risks and unexpected changes which have been appearing since COVID times the beginning of 2020.
My work at Automattic has been an amazing adventure this year. I’m proud of what we achieved with the company as well as with teams I work closely. WooCommerce Payments has become available in 18 countries and got a ton of new features, it’s powering thousands of online stores and is helping merchants to sell their great products all over the world! It’s incredible to be part of that journey and share it with such wonderful people and professionals. There are ambitious plans for 2022, but I won’t share them here, you’ll find out yourselves either by following my or WooCommerce Payments’s updates.
I’m glad that I started writing and sharing my thoughts with people a few months ago. It’s not easy sometimes and far from ideal, but I’m happy with consistency since the beginning of the blogging experiment.
Wellbeing has become important to me recently. I started to focus more on this part of my life as well as continuing to care about other’s comfort. Thinking is not doing though, so the “doing” step needs to be improved in 2022 😀
Pausing here for now to spend some time with my family, bye!
2021 is getting to the end and it’s a good time to reflect a bit on what happened during the last 12 months. So did I with the help of my coach and want to share a couple of interesting bits of it.
Energy
I worked hard this year at my job along with many fantastic people around me. But hard work takes energy, which consecutively affects the quality of life outside work and threatens the balance between the two. What I found out though is to maintain that balance and live a happy life I need not only effectively use my energy during the workday but also effectively restore it. Rest is as important as the work I do. Taking rest is necessary to do the work well and should be planned accordingly.
As part of the reflection with the coach, we were also looking at my activities giving the most energy. So here are the two winners of mine: solo trips (like the one I had this year) and skiing (my new hobby). They work differently to some extent but have at least one thing in common – they create a space where I am alone without access to daily routines. Sort of escape from busy days.
We also talked about how to apply that discovery on a daily basis in 2022 so I can always have energy, but those are only ideas yet to be tested, so not sharing them for now.
Surprises
The second part of the reflection was focused on things that surprised me most this year and two things popped out of this: my personal journey at work and how well the team has coped with all the challenges.
Without going too much into internal and private details I think if somebody would present me the plan one year ago with all the things which actually happened this year, I’d say with confidence it’s not realistic or at least too optimistic. Looking back I can say that constant learning, iterative approach, and the culture built within Automattic were the key elements of that success. That’s why for 2022 I’m not trying to make any precise plans, but want to stay ambitious, adjust as the situation changes, and enjoy the journey.
That’s it, now it’s time to apply those learnings – try to stay ambitious with keeping a good energy level and avoiding burnout at the same time. I’ll let you know how it goes in 2022.
Author: Camile Fournier Subtitle: A guide for tech leaders navigating growth & change.
TLDR; This is a very good guide on how the individual’s journey could look like in the tech company if they choose to follow the management track. It has plenty of management wisdom yet is delivered in a lightweight way giving directions for further in-depth exploration. Personally, I was very impressed by the density and quality of the thoughts in the book, so I will encourage every team member to read at least the first several chapters. Thank you, Camille, for this book!
The author
Camile Fournier (@skamille) is currently a Managing Director at Two Sigma. She studied at Carnegie Mellon University, worked at Microsoft, went from the tech lead to CTO at Rent The Runway, and took many other leadership positions in different companies. Here is a great quote from the book expressing the growth experience of Camille:
As the organization scaled, so did I. I had mentors, coaches, and friends who provided valuable advice, but no one was there to tell me specifically what to do. There was no safety net, and the learning curve was brutal.
In the “Manager’s path” book Camille shares her lessons and own experience as well as describes in many details different stages of the engineering management career. You can find more of her posts on medium.
For whom?
I think this book will be valuable for many people at different career levels, starting from middle engineers to tech leaders and engineering managers of any grade.
Engineers will benefit from better understanding their mentors and managers, taking a look at what leadership roles are, and getting prepared for the first steps if they decide to follow that path.
Current leaders will find some great tips and ideas for their day-to-day work as well as insights about senior leadership roles.
The book might be interesting for non-tech leaders too because they can learn a lot about the life of their colleagues from tech departments.
How to read
The book is very well structured and you can jump straight into the level of your interest. However, I’d recommend starting from the introduction and covering at least one chapter below and above the level of interest. And don’t forget to take a pencil or a notebook for taking notes. Believe me, you’ll want to do so. Personally, I enjoyed reading all the chapters one after another.
My impression
I want to say that the book is amazing and let you read it on your own, but that would be unfair to you 🙂 Each chapter has great thoughts and sparked more than one idea in my head.
Chapters about the levels I’ve already experienced (up to leading the team) resonated with me a lot. They had a lot of precise notes, observations, and tips. I wanted to scream something like “Yes! Yes! Yes! This is so true!” or “I wish all my teammates knew this!”.
Chapters about the next leadership levels were very interesting. They made me play with my imagination but still were much vaguer because I haven’t had such an experience yet. I also felt that life at the higher levels varies a lot depending on the context and organization culture which I believe is perfectly fine and expected for those positions.
Anyway, the book has left a very positive impression and I think I’ll read it again more than once.
My favorite quotes
I was thinking to pick three to five quotes for this section, but after making an initial list of 43 it was unrealistic to shrink it down that much. I struggled while was removing quotes from the initial list, so here are the ones I couldn’t get rid of. Some of them are very obvious and simple but still very powerful.
… experience of being managed is the foundation on which you build your own management philosophy. Unfortunately, I’ve come to see that there are people who have never in their careers had a good manager.
That is a very good definition of a problem in the industry as well as the source of trouble because engineering management is hard, and not every person steps into the role striving to become good at it.
Developing the sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.
Accepting the fact that you own your experience was the biggest game-changer not only in my career but in my life. Staying in the same spot while suffering and complaining is also the choice, but not mine 🙂
One of the early lessons in leadership, …, is that people are not good at saying precisely what they mean in a way that others can exactly understand.
I noticed it during the past year as well. No matter how clear the message sounds in your head it will land differently on people’s minds, so it might be a good idea to validate what people heard, e.g. by asking them for a summary or by taking shared notes.
… there is nothing worse than showing up for your big job with nowhere to sit and no access to the systems.
New people onboarding process is one of the key elements of team success at times of rapid growth. Welcoming new people, making them feel you were waiting for them, is a significant booster if done right. So make sure you allocate enough time to prepare for onboarding a new teammate. If don’t know how? Read the book for many great tips.
The idea that the tech lead role should automatically be given to the most experienced engineer, …., is a common misconception that even experienced managers fall for.
“There are more experienced people in a team” – several people mentioned this to me as a blocker for looking into leadership roles. In practice though, it’s absolutely not a blocker! In my opinion, it’s good when a leader knows he/she is not the smartest person in the room, so they have to bring other skills and tools for leading the team in the right direction.
My final advice is to remember that you can switch tracks if you want. It is common for people to try out management at some point, realize they don’t enjoy it, and go back to technical track. Nothing about this choice have to be permanent, but go it with your eyes wide open. Each role has benefits and drawbacks, and it’s up to you to feel out what you enjoy the most.
I hope this quote removes another common fear among tech folks looking at leadership roles. It’s a different job, you may like it or not, both are fine.
In the long run, if you don’t figure out how to let go of details, delegate, and trust your team, you’re likely to suffer personally. … Your time is too valuable to waste, and your team deserves a manager who is willing to trust them to do things on their own.
Trust your team, they won’t let you down and will save you from burnout.
Whatever the procedure is at your company, the process of coaching someone out should begin long before any performance improvement document is filled with HR, and long before the actual act of firing. One of the basic rules of management is the rule of no surprises, particularly negative one. You need to understand what a person is supposed to be giving you, and if that isn’t happening, make it clear to her early and often that she is not meeting expectations.
That’s probably one of the hardest things you need to do as a leader. Letting someone know they don’t meet expectations is usually a tough conversation, but avoiding tough conversations with the hope that things will get better soon is the worst path you can take. Poor performance or misbehavior should be addressed sooner than later because it harms overall team health. But, don’t rush by calling HR to kick somebody out of the team because everyone can have a hard time in their life. First, do your best to help a person with getting back on track, but if it doesn’t work out stay clear and honest with the person and help them to leave the company gracefully for the sake of the overall team.
Appropriate context is what helps teams make a good decision about how and where to focus their energy. As the manager, it’s not your job to make all of those decisions by yourself.
Yep, as a manager, you better focus the energy to create conditions where the team is capable to make decisions rather than deciding everything on your own. Autonomy is one of the basic psychological needs.
Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once.
It’s also a great way of developing talents in a team.
As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice modeling, right now: figuring out what’s important, and going home.
This year was very busy for me and for many of us at Automattic. One of my biggest insights from this adventure is for success you don’t need to work more hours, you rather need to work on the right things.
Remember, you’re not expected to know everything just because you’re a manager.
No comments, just remember that.
The processes should have value even when they are not followed perfectly.
People are not machines, they do mistakes, so consider making fragile processes more resilient or get rid of them at all, especially complex and fragile ones.
You have to be able to manage yourself if you want to be good at managing others. The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that dirve you crazy, the better off you will be.
I simply agree here, self-awareness, coaching, and other practices helped me a lot with getting better as a human and a leader.
If not convinced yet, believe me, there is much more in that book. I encourage you to buy a copy and keep it nearby on your bookshelf!
Photo by Vi Nowak on Pexels.comAudio recording of this post
You’ve written that final line of code and are pretty sure it should work now, you run it to double-check the code does what you were aiming to do, aaaand… It works! Yahoo! You did it! Now it feels like a good time to commit, push for review, sit back, breathe out, celebrate a bit, and jump to the next awesome feature in your long list of fascinating ideas! But wait for a second, there might be a few more things that would be nice to do before you ship your solution.
First of all, congrats! You wrote a code that works! This is a necessary step in the process of creating software, yet not the final one.
There is a nice post titled “Always do extra”. Although it’s focused on mastering hard skills and growing the expertise, the idea that outstanding developers always do extra steps resonated with me. Here I’m sharing five more steps great developers take after their code works.
1. Take care of the readers
Good product leaders know their customers and care about them, good writers know and care about their readers. There is a lot in common between writing and software development, so good developers know and care about their code consumers.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand
That quote clearly states there are two types of consumers of your code: computers and humans. While the code you just created can be successfully digested by a computer, it works after all! Can you tell the same about other developers? Will they understand your awesome idea? How much effort is required to understand your solution?
Those are great questions to ask yourself. In most cases, software development is a team sport. You’ll improve code written by your fellows, and they will build on top of your solutions. Chances are high there are different players in your team with different skills, experience, and domain area knowledge. So it’s time to make sure the code reads well by people with different backgrounds.
Although it may sound simple there are many things under that cover and it’s not about code style or prettifying its look, I assume there are linters and formatters already in place to automatically make sure team agreements about code style are followed. There are things like naming variables and methods, commenting on unobvious solutions or decisions, extracting pieces of functionality into reusable functions, applying the right design patterns, and many more. If you’re not familiar with those I’d recommend starting with Clean Code by Robert C. Martin (aka Uncle Bob).
If you already know the theory and have experience in making code readable, here is the tip from professional writers – take a pause before starting code cleanup and switch to something else for a while. When you get back you’ll be able to read the code with fresh eyes and more effectively spot areas for improvement.
2. Respect other contributors
Unless you just started with a clean project, the enhancement you made is not the first one to be shipped. So the reasonable question to ask yourself is are old features working after my change? I doubt your fellow developers and precious users will be happy to discover one day that the feature they love and successfully used yesterday doesn’t work anymore.
To answer that question you’d need to run some tests. How you do it depends on the state and size of the project, the specifics of the code changed, available tools, the overall dev process, and some additional factors.
In the best case, you have a good continuous integration pipeline (CI) with a decent set of automated tests that will run every time changes are pushed into the repository and the merge will be blocked if at least one of them fails. However, even if you have them you can save your time by running locally a subset of the automated tests covering the areas of the code which might be affected by your change. This will save you from getting back to the code after CI catches some mistakes for you. But it is worth doing only if the time and effort to launch the test environment locally is relatively small, otherwise, delegate this task to CI.
If you’re not so lucky and don’t have a good CI, there are at least two things that would be nice to do. First – try to run all automated tests you have or at least test critical paths of the project which potentially might be affected by introduced changes. Second – start talking to your team about the values of CI and automated testing, you may find a few good hints in this post.
3. Protect your solution
No matter if you were lucky or not on the previous step, I hope you see the value of CI and automated testing. So it’s time to make sure your own code has some protection.
The first kind of protection – automated tests – is needed to signal other developers if they unintentionally break your code. Depending on the scope of the feature, its importance, and complexity you might need unit, integration, end-to-end tests, or a mix of them. There is no single right answer on how much and which tests you need to write, you’d need to decide on the right balance of those yourself. Ideally, tests for the happy path, some expected unhappy paths, and maybe edge cases would be added. Doing so also highlights that those unhappy paths and edge cases were taken into consideration.
Tip: thinking about how to test your code early in the process leads to less coupled and better-structured solutions. Read TDD by Example book for more thoughts and examples on this approach even if you are not going to follow the test-driven development process.
The second kind of protection – error boundaries – is needed to prevent the whole application from exploding if there is a mistake in your code. Depending on what are you working on this kind of protection might be not needed, e.g. if unhandled exceptions are a necessary part of the solution. However, consciously thinking through them and adding or not adding catchers where necessary is worth doing.
There are good chances that the solution you’ve just made will be used not only by developers in your team or other teams in your org, and in the case of a popular product, there will be lots of people relying on your code. So it’s worth taking care of them as well by writing some docs, creating demos, or any other hints which would explain your solution from the product user perspective.
For example, QA folks would be happy with testing instructions to reproduce and test new changes, and end-users would be happy by getting up-to-date instructions in the product docs. Community members could benefit if a new library feature is listed in the docs with a good demo of how to apply it.
In many cases, this step might be not needed, but creating a habit of taking a pause and thinking about it will positively impact the product. People will love your solutions and product much more if it’s clear and easy to use them.
5. Take care of reviewers
We are humans and we’re not immune to mistakes, that’s why the code review process exists, and hope you have it in your team as well. Taking some steps to help your reviewer will make the process faster and more efficient.
Here are a few things to consider:
Commit messages.
PR description.
Find and ping the right reviewer.
Let’s start with commit messages. Good commit messages are a valuable source of useful information for the reviewer. Those are hints and a history of work progress on the issue. So worth reviewing them before pushing changes to the remote repository and editing where necessary. Interactive rebase is your best friend in this process.
PR description. It is usually the first thing reviewer will read to understand what’s the PR is about. They have plenty of their own work to do so it’s naive to assume that PR reviewer always has the same or more deep knowledge of the issue you were working on. Despite that lots of information could be derived from commit messages, PR description is an important element to onboard a reviewer. It’s a good idea to have a clear and concise title of the PR, a link to the issue it fixes, a short description of main changes introduced, testing instructions to run/reproduce old and new behavior, screenshots in case of visual changes, links to designs and other important discussions where key decisions were made, and so on. The key point is to save the reviewer’s time searching for all of this info to understand your work and properly review your code.
Once your PR is ready for review, the final important step towards effective review is to pick the right reviewer. Unless this process is fully automated or documented in your team you’d need to make a decision here as well. Hope by that time you have a good understanding of which parts of the codebase are affected by your changes, so requesting a review from a teammate who is familiar and knowledgeable in that domain is a good idea. Taking reviewer experience into account is also important, e.g. it would be an arguable choice to ask a new or a junior developer to solely review complex change affecting many parts of the codebase. Sometimes asking two or more people to review the changes is reasonable, especially if those are critical ones.
If you’ve done all the steps above, you must be in a good position! Go ahead and send your awesome change for the review! You’ve done a great job by taking those extra steps, however, that’s not the end of the journey yet. The code review is a really nice and interesting process and deserves its own story.
In the end, I want to share a great quote made by WordPress one day – Code is poetry. It’s not a coincidence you’re called an author even if you don’t feel like a traditional writer at all. No matter if your code is a poem, novel, short passage, or anything else, you have the readers! And it would be nice to think about them and love them as I do now while writing this post!
Photo by Towfiqu barbhuiya on Pexels.comAudio recording of this post
Being a leader implies a broad set of responsibilities and requires skills that differ from individual contributors’ skills. I was thinking about it yesterday morning and then the question came to my head “what are the most important ones?”. Huh, the wheels immediately started spinning in my head trying to find the answer. Then I remembered that limitations foster creativity (here are twoposts on this topic), so I decided to add a limit of 3 skills to make the exercise even more fun. So here are the top 3 of my choice.
1. Communication
“Communication is oxygen” sounds like a mantra in my head not only because it’s part of the Automattic creed, but because I feel it with my bones. I doubt there is a leadership book exists which doesn’t mention communication as one of the top skills for leaders or managers. I also think communication is the most powerful weapon in the leader’s toolbelt.
There is a lot already said and written about it, but through this year I’ve realized that being good at communication is not just being able to speak or write well and without mistakes. It’s much more – from understanding the theory of information processing by humans to resolving conflicts, from effectively expressing yourself to listening and creating a space for others to share, from stretching people to supporting them, from mentoring and coaching individuals to learning from them, and so on.
As you can see, communication is a very broad topic, so mastering and practicing various aspects of it will never hurt.
2. Sense of balance
Leadership is a very inaccurate science. There is no one size fits all solution and many recommendations depend on the context. That’s why I believe it’s crucial to seek, define, and regularly check the balance which works well for your case. That applies basically to everything – the amount of uncertainty affordable in the projects and processes, the amount of autonomy and control you want to have in a team, the amount of tech debt taken into sprints, the amount of time spent on learning and self-development, saying yes or no to many ideas and initiatives; the list may go very long.
No matter what was your past experience, it takes time to adjust balance in your current context, so pure curiosity, observations, and regular feedback loops are your best friends in finding the right balance.
3. Self-care
Supporting your team and its individuals is another extremely impactful way of leading the team to success. However, you won’t be able to do it well if your battery is drained. That’s why I think taking care of yourself is necessary, required, and mandatory in that role. If you like many others experience impostor syndrome or feel guilty about taking care of yourself, it’s time to reach out for support. Talk to your lead, talk to your peers, consider working with a coach or a therapyst, because sometimes it’s really hard to cope with. And last but not least don’t forget that simple aircraft instruction “Put the mask on yourself first”.
Note:this is purely my opinion as of today, after being more than one year in that role with a fully distributed team, after experiencing a team growth from 4 to 12 people, after experiencing a team split, team focus shift, delivering multiple projects, switching team focus, talking to and learning from many great leads, mentors, and coaches around me.
I’m curious what would be your top 3, so I would be happy if you share them in the comments under the post.
Photo by Dmitry Demidov on Pexels.comAudio recording of this post
I’m pretty new to blogging but what I like about it so far is that it’s a great way of sharing an individual perception of reality. That’s why I think the author’s identity is an essential part of the blog. That’s why many blogs have an “About” page and it’s a great way of getting familiar a bit with the author of the posts you read and hopefully enjoy.
Another great thing about people is they are very different and creative by nature and that applies to their blogs and about pages as well. However, so far I’ve seen only text and images as the most common content on the about page, mine about page is not exclusion. That’s perfectly fine, especially if you like me have the good old stereotype that “blogging is writing and writing is text and images”. However, Blogging for beginners course by WordPress.com Courses and folks at Automattic, challenged that setting in my head, and I realized it’s not like that anymore. Somehow my brain ignored the fact that video-based services like YouTube, Instagram (to some extent), Tik-Tok, and so on have millions of content creators who are bloggers. Podcasts became very popular too and can be considered voice-based blogging! So why not use voice, audio, and video in the classical web-based blog?! Why not use other media in addition to text and image on the About page to share your identity with readers and establish a better connection?! I don’t have a good answer for you 😛
So here we are, got to the point and the key purpose of this post – to connect the dots and give you a chance to hear the voice behind the blog. I don’t know yet if I’ll make audio recordings of the following posts, but I smile every time when I imagine how my voice sounds in your head while you read the posts.
Thanks for listening/reading and hope you’re not annoyed by the voice 🙂
Vasily Belolapotkov 