Sticking to the process of achieving my goals has always been one of the most difficult obstacles to overcome, both on my way to becoming a better professional, and in my private life. I have found that in some areas I need to make an extraordinary amount of effort to keep myself on the right track, no matter how S.M.A.R.T. (Specific, Measurable, Achievable, Relevant, Time-based) my goals are. I couldn’t understand why in some cases I was able to make the desired progress, while in others I kept failing. Was it a matter of talent I was missing, or a skill I haven’t acquired yet? I have seen the dots, but I didn’t yet know how to connect them.
"Geniuses still make mistakes and having brilliant ideas and elite programming skills don’t guarantee that your software will be a hit. What’s going to make or break your career is how well you collaborate with others", say Brian Fitzpatrick and Ben Collins-Sussman in their book "Debugging Teams. Better productivity through collaboration". It shows that crafting the ability to collaborate is equally important as learning new programming languages and mastering the ones we already know. Let’s take a quick look at how this book can help us to become a better team player and a better team leader.
There are books you read once, and you don’t plan to read them back again any time soon. However, some books are so influential and valuable that when you decide to study them the second time, you realize that it was the right choice, and you could make this call a few years earlier. Today I would like to show you a book that belongs to this second group — no doubts about that.
We are software developers. Our daily duty is to write programs. We spend a lot of time and effort into doing the right things and doing them right. At some point, the production launch day comes and depending on our level of confidence - we are calm and ready for the first wave of unpredictable users, or deadly terrified.
This is the second blog post in "Programmer’s Bookshelf" category, and today I would like to share with you my opinion on the "Deep Work" book by Cal Newport. It’s not about programming, but it’s still beneficial to any software developer out there.
When I get the paperback copy of the "Programming Groovy 2" book back in the June 2017, I was wondering if I can find something new or exciting in the book that was written in July 2013. It took me almost 1,5 year before I have finally put the book on my desk and started reading and playing around with the examples. As a veteran Groovy developer, I have to say - it was worth it!