[jauntywundrkind]

Devs I think are somewhat withdrawn, as a result of being under the yoke of ticket delivery. Being given the trust respect & capacity to roam & improve as we wander about systems is rare; we're judged on how quickly the task at hand is done. This is such Luddite, chained-to-the-machine endpoint that we are at.

And it skips past so much of the raw joy & auto-enrichment loops that happens when there's time allotted to discovering and improving the system as you go. DIYers have such amazing enrichment loops, making systems work better for themselves all the time. Not just the much vaunted fast delivery now, but the ability to keep iterating & expanding & delivering without your constructs starting to clash & thrash.

I love love Fogus's 100:10:1, on having many tangible places outlined where one might do something. Still dedicating yourself to something, but also giving yourself permission to hop around. Follow what feels good. https://blog.fogus.me/2015/11/04/the-100101-method-my-approa...

[Ed: s/yolk/yoke/, thanks for the fix folks!]

[ozim]

That is why I promote FaF - fix anything Friday and try to fight off sprint load inflation, where it would be expected from team to do more and more. Then also promote “dev alignment” where devs come together to discuss architecture improvements or pick approaches.

[cwalv]

IMO it should be 'fix anything when you feel like it.'

"Sprints" have given agile a bad name (to the extent it has a bad name, as in gp's complaint). The point is to optimize for changes, as they're inevitable, by: 1. Keep the code in a 'clean' (testable, free from cruft, etc) state continuously 2. Release continuously 3. Embrace YAGNI

If short, regular sprints help with those things, use them. But sometimes they don't

[ozim]

Problem is you want to have changes going through process. It has to go through other devs, it has to go through QA, if its user affecting it has to go through business. Yeah like we have linters and auto formatting so no one is arguing on that in my team. We don’t have superficial fix anything, people fix stuff that can affect users but as they work with system they notice improvements.

Having that arbitrary deadline of a sprint helps to synchronize people. Because there will always be that one change that is released but not touched by QA or we need some business analyst to review feature on test server to make sure we did right thing.

Keeping code in testable state and somewhat clean state is easy like I mentioned linters, code formatting automatically. Keeping system changes as in frontend/ backend / third party services aligned is not because it is not something you can just write in one place in code.

[chrisweekly]

yolk (yellow part of egg) -> yoke (harness for beasts of burden)

EDIT: but also and more importantly, your point is Excellent! 100% agreed - the ongoing process of discovery and continuous improvement of a codebase are signs of the best kinds of ownership / attachment, and sadly represents a huge blind spot and missed opportunity for the majority of "dayjob" projects.

[from-nibly]

I think you mean Eggcelent.

[elevatedastalt]

yoke*