This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-29
Channels
- # babashka (64)
- # beginners (60)
- # calva (10)
- # circleci (3)
- # clj-kondo (62)
- # cljdoc (6)
- # clojars (2)
- # clojure (152)
- # clojure-europe (19)
- # clojure-nl (3)
- # clojure-uk (18)
- # clojurescript (50)
- # clojureverse-ops (12)
- # core-async (21)
- # cursive (6)
- # data-science (1)
- # datomic (17)
- # events (14)
- # fulcro (64)
- # graalvm (20)
- # graphql (5)
- # honeysql (14)
- # jackdaw (3)
- # jobs (1)
- # jobs-discuss (22)
- # kaocha (2)
- # lsp (9)
- # luminus (8)
- # malli (30)
- # meander (31)
- # other-languages (1)
- # polylith (8)
- # re-frame (15)
- # shadow-cljs (85)
- # specter (2)
- # sql (11)
- # tools-deps (56)
- # vim (39)
- # vscode (7)
- # xtdb (16)
But it's not a question, it's peer pressure, it's pointing out disagreement and that you shouldn't express such vague, negative feelings towards industry conventions...
Itâs difficult to disagree or have a conversation on something when the argument is that vague. The question mark is to invite more information without breaking the flow, not to shame someone into hiding
Intent can be relevant, but it's ultimately not the most important thing in clear communication.
We have an unfortunate tendency to make simple guidelines complicated, especially if they are organisational. Formalising the informal without rigour and categorising while ignoring unknown context. Agile is one such thing http://apparently.It can somewhat be boiled down to: Letâs not pretend we can specify and understand a thing in its entirety and focus more on discovering what it is together, closely with the people that use it. It is a call to accept our fallibility but also to respect our ability to grow, learn and empathise. Uncertainty is unavoidable so letâs focus more on the human side and build trust and understanding.
Yes, imagine Agile + Police, which is a very hierarchical orginisation. We had Senior Product Owners
while we did not even see the Product Owners much.. Getting things done was far from Agile..
Product owners, something masters etc. are just new terms to describe top down hierarchical organisational structures. Just call them managers and be done with it. âBusiness people and developers must work together daily throughout the project.â and âThe most efficient and effective method of conveying information to and within a development team is face-to-face conversation.â All of these things have a strong underlying theme, which is direct, human connection based on trust. If you take that away, everything falls apart and you are stuck with a proliferation of rules and processes that try to patch over this defect.
But somehow there are people who are so afraid of trust, that they felt the need to invent all kinds of rules and games around this simple idea, perverting it into something completely unrecognizable.
This is very pronounced in discussions where someone claims that âYeah, XP is nice and all but it only works with excellent/exceptional peopleâ. Well how do people become excellent and exceptional? Surely some of us have it easier than others but the bulk of it is practice and experience and the willingness to learn. We cannot learn if we cannot make mistakes, and we cannot make mistakes if we are not free.
Yeah, but most "agile" setups are not about freedom or being the best, it's about digital taylorism, it's about the new person being able to integrate asap, without additional training period, it's about them being able to "ship solutions/features" regularly, not about them making any mistakes. Mistakes are welcomed in an environment when it's understood that we are experimenting, but no company I worked at was this the norm, the accepted default, instead, in the best case scenario, you could spend time and got support to do it on the side.
Just kind of sharing random thoughts. Your english is fine, certainly better than mine!
What I was trying to say is that if we donât fully understand the hole, what works and what doesnât in advance, so we ship features quickly and regularly (throwing things at the wall and see what sticks), then that is still experimentation, or rather discovery, regardless of whether we label it as such or not. And whether we want it or not: mistakes will happen. I donât think that this is inherently bad. Mistakes happen so we can learn. Itâs very unfortunate that in some environments, this isnât seen as something positive. I couldnât cope to be honest.
It's not just not bad. But this whole topic is a bit too much for this discussion I think: https://www.art-sciencefactory.com/complexity-map_feb09.html
However, the way you put it, it seems as if people not allowing experimentation is all environments is a bad thing - which is not what you said, but could be seen as if you were saying something similar. Also, it seemed as if you were saying if people were doing it because they just don't understand it, but that's also not the case, in most cases it's done because they do understand it.
Happy to talk about it, but not to write more. It's been a lot already and can't be too specific without writing a novel đ