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 Decomposition of functional requirements into atomic User Stories doesn't mean that activity of elaborate design is redundant - there's always a need of shaping the system's conceptual model: usually at various levels of detail (for different reader categories) & taking into...
> TL;DR Thank you for reading my blog posts through all these years, this is the post number 500 (!) & the good thing is that I still enjoy writing, so I guess you can expect some more from me. What is 500 and rising? My blog post counter. Yes,...
> TL;DR Even today, many treat leading teams as a modern form of livestock herding. Limit the information (to avoid distraction), assign tasks, make a checkpoint each week, force controlled crunch before deadline, rinse & repeat. Fortunately, we can do so much better than that, if we manage to...
> TL;DR We spend ridiculous amount of time on verifying job candidates' technical proficiency, analytical thinking, communication skills, but we rarely ask them for what they really aim for. Companies enforce their career models & internal goals / definitions of success w/o examining what really drives a potentially...
> TL;DR Surprisingly many engineers prefers to be explicitly told what to do, be given a clear end-to-end specification & the worst of all - have someone else representing them to the end of the world, translating "the current state of things" into the language everyone else...
> TL;DR Getting end-users' and sponsors' feedback is crucial if you really want to build (/enhance) a good product, but it doesn't mean that you can let them "think with solutions" and mindlessly introduce suggested changes yourself. Business insights ought to be reforged...
