Geek, agilista, blogger, codefella, serial reader. In the daylight - I navigate & lead software engineering. #lean #design #aws #elixir #analytics. I speak here for myself only.
> TL;DR Many IT people (mainly executives & various managers) are guilty of building the walls between business and engineering parts of organisation: by introducing gated demand management, communication via specification, cooperation through proxy people and siloeing the competences they hope to achieve more order & control, additionally reducing...
> 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 This is a job ad. Not a typical one, but still. I'm looking for 1-2 .NET software engineers with an insatiate apetite for serious challenges. Job itself is about methodical tending to brownfield codebase, but not by firefighting, but applying mature development practices: convention tests,...
> TL;DR Hindsight bias is fascinating - it comes easier & easier to fool ourselves the more time passes by. We make things appear easier than they were (& are), ignore the changes of the context on the way (by judging everything from today's perspective), in some...
> 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...
