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 people in the industry are so used to free high-quality content available on-line, that they can't accept the simple fact you actually have to pay for some stuff. Software crafts(wo)men who should be the first to preach for digital rights respect are...
> TL;DR GDPR is almost here, Internet is already full of various analysis, digests, summaries, interpretations - but 99% of them is made by (wannabe) lawyers for people who understand "lawyerish". However what counts in the end is the lower-level perspective: how does GDPR impact the design...
> TL;DR Every independently thinking person can easily recognize all the enterprise talks regarding "engagement", "motivation" & "ownership" as stinking pile of worthless, corporate rubbish. Neither knowledge nor creative workers can be so easily "tricked" (even if they can, in fact...
> TL;DR Contrary to the common belief, proper conceptual decomposition of large software solutions doesn't require any particular architecture patterns in place. Being service-oriented doesn't necessarily enforce any constraints on build or deployment - it's a matter of proper, highly aware design which...
> TL;DR Building software while "on auto-pilot" doesn't work well - operational automation is more than advised, but understanding (in-depth) why-you-do what-you-do is absolutely essential. However, there are certain practices many stick to, without really understanding their purpose & descendant effects. One of them is...
> TL;DR Architecture should be kept as close to code as possible, same applies to docs - otherwise they are a subject of near instantaneous entropy. But what about possible items to be fixed - differences between architectural vision & actual implementation, possible deviations from agreed conventions. My proposal...
