Just Build It...

A lot of coding work, and modern work generally is all learning. IE, a lot of tasks consist mostly of learning to complete the task. There's just a lot of cascade. The language, library, codebase, prerequisites specific to the task, etc.

Often you spend half the day learning about the task, then learn or refresh some bit of required technique or knowledge... then you just do it.

In carpentry, engine restoration, cooking or whatnot... this is typical of early days. Every early carpentry project requires some learning. A new cut, a join or glueing method. As you mature in the discipline, the density of novelty and learning decreases.

"Learning" is a bit of a catch all. Learning about the product, library or API might just be literal information gathering. Other "learning" might be skill building, requiring practice and repetition to "learn." EG, brushing up on regex to deal with some misbehaving code.

In any case, we tend to be pretty resistant to openly practicing, or training ourselves. We prefer to err on the "knowledge gathering" side. Or... we do agree to practice, but adopt a low effort "just practice" mentality that isn't effective. Layer these tendencies onto modern work, where the divide between learning and doing is unintuitive and vague... most of us are not practicing enough to do what we want to do.

"Just build" is, IMO, mostly a hack to make us practice with sufficient effort and persistence for learning to happen. If you have a thing you want to build, you need to practice building it. The proficiency you acquire is often more useful and valuable (even for the task itself) then the concrete output... until a much later stage in the game than we intuit.

I think "The Problem with Agile," especially at this point, is mostly upstream of any implementation details.

What kind of an organisation is going to adopt a packaged management method like that? Cargo cult adoption of practices, language, job titles, consultants, tools and formal certifications... The company that invented agile would never have "gone agile" in 2023.

I'm not saying that agile can't work. I'm saying that an insurance company "adopting agile" is an insurance company buying a trendy management method for their engineers. It matters not if the method is called agile or a 1972 booklet from the USSR. Practices, practiced blindly are rituals.

I see it everywhere... not with "hundreds" of teams but enough teams over a 12 year career in consulting to make this not anecdotal.

In "So Long and Thanks for All the Fish", there's a forward Douglas Adams wrote for a book by another author which was unfinished. He related two stories: the first about an ancient Greek poet who would spend the morning reciting verse, which one of his disciples would write down; then he'd spend the afternoon throwing the vast majority of it away. The second was about another author who'd type out a page of a novel and stick it on his wall near the bottom; every so often he'd page off the wall, type in an improved version, and put it on the wall a little higher, until all the pages were at the top.

His point (speaking about the other author) was that the book was "unfinished" both in the sense of incomplete, but also "unfinished" in the sense of unpolished; it was a warning that the quality of the writing would not be the quality the readers were used to from that author.

(Which was apropos to include in "So Long and Thanks for All the Fish", since it was also a novel started by Adams and not "finished", in either sense.)

It's a hard thing to do, to just sit and write something you feel is garbage. I think I've mostly managed to get to the point where I can do it for coding, but not really for text yet.

Like the sibling comment here, I've seen this plenty of times too. Not on "most projects" or "most places", but certainly on most spectacular failures I've witnessed.