> TL;DR In our everyday software development work we tend to under-valuate the meaning of type systems, their expressiveness & role they play in proper domain modeling. Due to poor reflection of true nature of data, we increase error-proneness & readiness of the codebase - all of that because...
> TL;DR Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future&...
> TL;DR No org composition is perfect & given forever - things that didn't matter much when you were 10 may suffocate your whole engineering unit when it grows to 30. That's why engineering units should keep evolving - to make sure that local maximum...
> TL;DR Being a Software Architect is not a Super Senior Developer role, in fact its both leadership & management (these two are not the same) role that should act in parallel (& independently!) to other management dimensions (e.g. product, engineering or project). Based on my personal experience,...
> TL;DR I keep seeing the term "Technical Debt" used as some sort of justification for bad engineering: "we had to pick our battles", "it will be fixed when it's time", "it's what happens to all apps with...
> TL;DR Judging software engineeer's potential is not easy. Skill is in fact of secondary importance, experience may be a subject of diminishing returns, passion can manifest in very different forms. Fortunately there's one, particular personal trait, the one I call an Ability To Execute...
