Descriptor

I will be moving this blog to a new domain and may lose some of the subscribers if you're using RSS for example. I hope that the email list can help with the migration (modal + sidebar). In the future, I also think about sending interesting articles and news about tech and books, but all the things that interest me :) Maybe that's something that you would find worth your effort to subscribe. >>>  Signup page  <<<

Recently I'm reading a lot less about tech and more about culture and have a bunch of things I can recommend: 21 Lessons for the 21st Century Falling into Faith SHAME STORM SJWJS On my todo list: The Coddling of the American Mind As you probably can guess my view changed in the last couple of years on a bunch of topics. I still consciously try to remain in the middle in the discussions on the topics like `women in tech` as I don't want to be associated with actions of the most devoted believers. For example,  GitHub's ElectronConf postponed because all the talks (selected through an unbiased, blind review process) were to be given by men.  is far from  How blind auditions help orchestras to eliminate gender bias .

 I was listening to a podcast episode:  Command Your Focus and Attention on What Really Matters with Chris Bailey  and noticed a really good analogy. " What allows traffic to move forward at a solid space is how much space exists between the cars on the highway" What struck me about it is that I can use it to explain team productivity in different organizations I was a part of. Some of them tried to pack the sprint with tasks to the full, but in some, it was ok for the team to pick a 'safe' amount of tasks so that they could be sure to accomplish them. Before I was thinking about the benefits of slack time that allows the team to work on important things (not only urgent) and to have space for urgent things if they show up. The great feeling of accomplishment when you finish last scheduled task day before the end of the sprint and can tackle additional bug or two or the confidence to spend additional hour making code more maintainable before finishing the

Today I've watched a presentation by Marcin Stożek called  How to train your BASH  and wanted to remember the most interesting points for later. 1. It's best if you follow a style guide There seems to be only one though  Google Shell Style Guide . 2. You can set Bash to  "strict mode"   It sets more human-friendly defaults and makes sure you won't miss any errors in your scripts. #!/bin/bash set -euo pipefail IFS=$'\n\t' 3. Shellcheck Turns out there is a tool called  shellcheck  that can help you write scripts that you intended to write. Best thing is that it explains what's wrong and gives you suggestions on how you can fix it. 4. You can enable 'debug mode' when running your script Just pass " -x " to the script eg.  >  bash -x ./my_script.sh 5. Use Pure Bash No one wants to see weird errors when running the script on a new server so it's best if you avoid using external programs in your

This tweet made me remember my own pondering of the exact same question and how hard it is to guess what is going to be relevant in the future. A lot of people answer that by saying that you have to always learn but the question is not "Should I learn?" but "What I should learn?". Unfortunately, no one can predict the future. I would even say that the question itself is flawed. I'm reading Farnam Street blog for some time already and one of the last posts goes deeper into this problem: What’s Staying the Same ? If you start looking for things that are likely to stay the same you will find a lot of things that are worth learning and they should be relevant a lot longer than the newest fad. More to read: Lindy effect Algorithms to Live By

I liked the idea of the book form the first time I've seen the title and fortunately, it lives up to my expectations. It's not perfect, but it rekindled my curiosity towards math and algorithms. Bringing them to everyday problems makes them much more interesting. The only thing that I'm missing in the book is the application of algorithms in business settings. For example, when I mentioned this book Mateusz K he has sent me a  blog post of  Pieter Hintjens: Amdahl to Zipf: Ten Laws of the Physics of People . For example,  Amdahl's Law  mathematically proves the argument from  The Mythical Man-Month  that you can't just add new people to the project to deliver it faster because of the cost of synchronization. I want this post to be a reminder for myself of the most interesting ideas in the book so if you want to savor it yourself just remember that it's worth buying. Rating: 9/10 Contents: 1. Optimal Stopping Probably the most interesting from thi