In this case I stumbled upon a problem (trying to dig through the SYN handling code, specifically [1]) and sat down to understand it. When I finally "got" it I

In this case I stumbled upon a problem (trying to dig through the SYN handling code, specifically [1]) and sat down to understand it. When I finally "got" it I moved on and forgot everything. After couple of months a colleague asks me a question and I think - oh boy, if only I wrote about it when I still understood it! I also regularly ask smarter people when I'm lost. On correctness, let me cite my boss: > Never underestimate the value of shipping. Ships blogs, > open source, pull requests, tweets, products, etc. > > It's better to ship something "wrong" than ship nothing at > all. You'll get feedback that you'd never get if you just > talked about an idea. I don't think being 100% right all the time matters. On every mistake I make I learn and it's easy to fix a problem in a blog post! I generally think for non-trivial technical stuff, it's better to create some documentation when previously there was none, than to get it 100% correct. Another example: many "man" pages are technically correct but useless. My favorite example [2]. You would be blessed if you could take 10% of the most useful options and actually explain them to human beings. [1] https://elixir.free-electrons.com/linux/v4.14.13/source/net/ipv4/tcp_ipv4.c#L1324 https://elixir.free-electrons.com/linux/v4.14.13/source/net/... [2] https://linux.die.net/man/1/ps https://linux.die.net/man/1/ps