Mir station burned after 15 years of service

Almost on this day, 20 years ago, Mir space station descended into the atmosphere, and burned after 15 years of service.


  1. 5 steps for Disagreeing Effectively
    • Check if you can complete the sentece: I don’t agree with X because. Otherwise, don’t bother to disagree further. Your “because” can be anything, but must be articulated.
    • Ask around within your trusted circle first. Even when you hear you’re not right, it’s OK as it will prepare you for the real confrontation.
    • Frame all the options. It allows to understand the scope, forces to understand the other side, makes you trustworthy.
    • Find out all the root assumptions behind all the options from everybody involved in the disagreement. Your conclusions coming from it might be still different, but it’s much easier to understand why is it so.
    • If you still can’t agree, don’t afraid to escalate it to the higher decision-maker. Never, ever be afraid. Don’t forget about including all the stakeholders. When all the steps above are done, then the decision, whatever it is, becomes fair.
    • You won’t win all the disagreements but it’s OK. Sometimes (or often) right clarification of the situation is more important and builds up in the long run for everybody: the project, the team, and yourself.
  2. Advances in XCFrameworks and its pre-read Supporting XCFrameworks. Not long but concrete summary of what XCFramework is and why it’s so great.
    • Binary frameworks as Swift Packages
    • Automatic Apple Silicon support
    • No need for fat binaries
    • Debugging symbols right away inside the framework
  3. Frameworks: embed or not embed that’s the question. TL;DR: embed dynamic libraries, do not embed static ones. But it’s a bit more complicated, of course. Or just use XCFramework ;-)
  4. Encrypt DNS in iOS 14 applications. How to: hide what DNS host are you checking, avoid hijacking, or blocking it.
  5. Quantifying Technical Debt.
    • Tech debt is not “ugly code” (it’s just an opinion) or written by “bad devs” (best devs can create monsters in limited time)
    • If you look for the real tech debt, that maintenance load is important, and increasing time for changes
    • The real problem is when there are areas which nobody wants to touch
    • Don’t reach the moment when the team starts to think about ground-up rewrite, improve earlier