New Domain

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 CenturyFalling into FaithSHAME STORMSJWJS 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.

Sprint stretch goals are harmful.

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 task.

Now with…

5 things I learned from "How to train your BASH" by Marcin Stożek "Perk"

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.


set -euo pipefail


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 ./

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 scripts. 

There is much more in the presentation so …

You want to stay relevant as a software developer for the next 10 years?

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 effectAlgorithms to Live By

Book Review: Algorithms to Live By: The Computer Science of Human Decisions by Brian Christian and Tom Griffiths

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 this chapter was the ru…

Book Review: Masters of Doom by David Kushner

The book that I wanted to read for a long time. How was it?

I have to say that it's really good. I learned a lot about Id and both John Carmack and John Romero - how their lives looked up before and during the creation of the most know Id Games like Doom or Quake. What was depressing but also making it so much more real is how much politics and infighting happened between all those people working in the industry at that time.

The only downside for me is that there's not much about the technology side of things. There is a paragraph here and there but most of the book is about two John's allowing you to take a look inside their heads. Maybe another downside as not native speaker would be the font - that made it harder than necessary to read.

All in all, I highly recommend it. 8/10