Model: Agile Fluency
https://martinfowler.com/articles/agileFluency.html Lens: Model_ estimates in Agile Fluency Lens: Model_ team composition in Agile Fluency
LIST
https://martinfowler.com/articles/agileFluency.html Lens: Model_ estimates in Agile Fluency Lens: Model_ team composition in Agile Fluency
I am looking for a job 1. in a growth company (not a company in a declining market) 2. in a team we can grow into a high-performing team 3. where I can apply technical excellence (continuous delivery, devops, agile) 4. practice & learn writing adaptable software (aka ‘agile code’ or ‘maintainable code’) (1) growth company, is what most recruiters know (2) team culture, is what some recruiters partially know (3) technical excellence, is what few if any recruiter knows (4) adaptable code, is what no recruiter knows...
If I use the following filter, it’s OR filter: {tags: {elemMatch: {contentful_id: {eq: $tagId}, name: {eq: "published"}}}} because filters over multiple fields are OR filter: { tags: { elemMatch: { contentful_id: { eq: $tagId }, name: { eq: "published" } } } } resulting in tag.id === $tagId OR tag.name === “published” If instead I use (abuse) the different matcher things for the same field, it is AND filter: {tags: {elemMatch: {contentful_id: {}, name: {eq: "published", in: "i....
This is part of a larger Story_ slicing stories We kept coming up with constraints that made the story simpler and simpler to implement. Not just simpler in code, but also in complexity. Beforehand it was already known to me that adding features to a program, increases the complexity exponentially per feature added, rather than linearly. Because every existing feature can cause problems for the new feature. So it’s much easier to add the 3rd feature than it is to add the 10th feature....
A couple of us in the team wanted to experiment with slicing stories smaller. And hammering out some of the details about complexity. So we came up with slicing smaller. At the time we were working a bit less as a team than we wanted to. So we wanted to add something to prevent pushing ideas through without the buy-in from the entire team. So we added another part to the challenge....
This is part of a larger Story_ slicing stories It’s pretty easy to push one’s opinion though about smaller slices. And it’s even easier if there is multiple people sharing that view. But that doesn’t build the team, instead it damages it a bit. Feeling misunderstood, feeling like your opinion does not matter, self-silencing your ideas. All of these are serious withdrawals from someone’s Model_ Emotional Bank account. This can happen occasionally, and when the balance is high enough, it isn’t that harmful....
Like so often when I’m thinking deeply, I have discussions with myself. Arguing back and forth. When exploring the insight Opinion_ only a beautiful success is worth having I got a immediate ‘counter-argument’ to this entire insight: "But work/life/reality is not a game!" To which the immediate replay came: "Yes it is, it's simply a badly designed game" Model_ life is a badly designed game
Part 1 - Paradigms & Principles Inside out Model: paradigm Model: paradigm shift Model: principles (character ethic) The seven habits - an overview Model: habits Model_ Maturity Continuum Model: effectiveness vs efficiency Part 2 - Private victory (habit 1) Be proactive Model: between stimulus and response Model_ Influence vs Concern (habit 2) Begin with the end in mind Personal mission statement Model: personal center - healthy vs unhealthy (habit 3) Put first things first...
Fiction, fantasy book. It’s amazing, seriously. This is the single best book I’ve ever read. The ONLY bad thing about it, is that the third book in the series is not written yet. Series: The Kingkiller Chronicle The Name of the Wind (2007) The Wise Man’s Fear (2011) The Doors of Stone (2020) Not the third book: The Slow Regard of Silent Things (2014) I know it’s unfair to this book, but that’s just how much I want the third book....
Business success makes the company. TL;DR many teams huge business success lousy code I work with a lot of teams that have huge business success, but have really lousy code. You go to a company, and you see they are really successful as a company. You look at their software an you: "Oh my, what is going on here? What is wrong with this code?" All these companies are really successful with really lousy code....