This book is work-in-progress, the structure of it is [[Cynefin framework|emerging]]. This is a living playground to capture thoughts about how to solve business problems with technical solutions and engineering. This place accompanies a [more formal blog]( of mine. ## Meta *Why I keep this place and some thoughts on writing* - [[Why even write a book? (80%)]] - [[Principles at the core (70%)]] - [[More reflections on principle discovery (80%)]] - [[Collection of quotes on writing (90%)]] - [[Toolkit for writing (90%)]] ## Preventing waste in software *Conventional approach for delivering technical solutions seems broken. Reflections on how to solve that.* - [[On building waste]] - [[Map of risks]] - [[Back to the business problem]] - [[Lagging and leading metrics]] - [[Map is not the territory]] - [[Genchi Genbutsu, see first-hand]] - [[(Tech tip) there appears to be flexible and free business-intelligence platforms, suitable for report experiments]] - [[(Tech tip) star schema might simplify BI queries]] - [[Brainstorm bets to move the metric]] - [[Gather evidence early]] - [[Discovering risks collaboratively]] - [[the most useful metaphor found so far]] ## Tackling complexity *Practical everyday tools to tackle complexity and getting clarity* - [[Big Picture overview]] - [[Decomplecting intertwined things]] - [[Cynefin framework]] - [[Tables and matrices]] - [[The Pyramid principle]] ## Project work and mindset *Thoughts on project execution from the start to finish* - [[Goals for the first X weeks of a projects]] - [[from estimates to time constraints]] - [[embracing the grind]] ## Architecture & System Design *Thoughts on key architectural decisions* - [[Value of architectural decisions]] - [[Buy vs. build]] - [[The value of boring technologies]] - [[SQL vs NoSQL]] - [[Batch vs. real-time]] - [[The value of idempotency]] #### unsorted - [[there seems to be business value in letting customers know what has been build, for example via release notes]] ## Working collaboratively #### relationships - [[a good way to approach work relationships might be via caring about the other and challenging directly]] - [[1-on-1s seems to be tighly related to caring]] - [[to work well, it seems to help to have psychological safety, with autonomy, opportunity for mastery and shared purpose]] - [[open-mindedness]] #### agency, cultural change, negotiations - [[it appears that one might cultivate agency even when the work environment doesn't support it]] - [[cultural change might be brought from the bottom-up, converting people one-by-one, patiently]] - [[principled negotiation might be more effective than hard or soft negotiation]] #### facilitating meetings - [[for meetings, it seems to help to have something shared (and visual) to look at to increase engagement]] ## Coding & Engineering *Tackling feasibility and modification risks* [[it seems that developers spend most of their time figuring the system out. Thus, is seems reasonable to write code with the aim to help others understand the code faster.]] - [[changes to the product might be done faster if things that change together are located together]] - [[thoughts on sharing code]] - [[Regarding code style, it appears there is value in consistency]] - [[alignment on key concepts seems to tackle value risk and usability risk and might increase speed of change]] - [[it seems to help when code is written like a story]] - [[painfully descriptive variable names seem to speed up code understanding]] - [[declarative style appears easier to reason with once you grasp the nature of it]] - [[external data might be unexpected, early data validation could help]] - [[errors might be resolved quicker if they contain extra info geared towards the intended audience]] - [[dicts could be simpler than lists]] - [[consistent semantics across the same JSON layer seems to help prevent errors]] - [[booleans ight make code harder to maintai ]] - [[tactics to make code easier to maintain]] - [[tactics and strategies to write tests]] - [[thoughts on an ideal programming language]] #### Storage and databases strategic/architectural choices: - [[choosing an id]] - [[Strict value checks might help to fail-fast and prevent unexpected state later]] - [[Sooner or later, events might be needed for the core part of the model. So it might help to store the events from the start]] every-day tactical choices: - [[Conventions for column name modifiers might help speed up understanding the database schema]] - [[DB migrations seem to simplify SQL schema management quite a lot]] - [[Relationships could be visualized easily with ERD diagrams]] - [[SQL queries could be simplified with some common techniques]] - [[config values could be stored in a table with one row only]] #### DevOps and operating the system - [[the 12factor app seems to describe reasonable default practices for service devops]] - [[incidents - approaching an incident as a learning of a complex system seems to lead to higher safety compared to blaming and quick-fixes]] ## Maximizing the distance travelled - [[the important not-urgent quadrant seems to contain the highest long-term value]] - [[the discipline of continuous improvement]] - [[Strategy could be approached with Wardley Maps]]