If your workflow feels comfortable there's really no need to change it in my opinion. The reason I do this is to avoid the frustrating feeling that I'm spending all my time moving around in the text file rather than actually making the program. It's less about speed and more about feeling good while programming.
> But for the remaining 2%, it's provably true that mouse is better
This is definitely true. The thing is that using the mouse is a habit, and until you break it, people find themselves instinctively using it in situations where it would be better to use the keyboard. So the 'hard' mouse disable is more of a 'going cold-turkey' type thing to try and break the habit. I agree that once it's broken it makes sense to relax this.
It's undeniably true that estimates are often driven mostly by what number will be acceptable. But it doesn't invalidate the points the article makes. Even when this distorting element of business drivers are removed, estimation is still very hard.
You might get reprimanded if you give accurate estimates - that doesn't change the fact you mostly can't give accurate estimates even if you wanted to.
I think you have that exactly backwards. ONLY successful ideas are being debated more than 20 years after they are proposed. Only successful ideas spawn reaction and counter-reaction, which lead to its evolution - which you say is not happening, but certainly is, as evidenced by the tree of methodologies that branched from it.
In that respect (which might not be the one the coiners hoped for), capital A agile has been extremely successful.
> My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them.
My new project deps file is always literally "{}". I love that that's all I need to do to start doing stuff. I add a couple libraries as needed. Maybe at some point an alias or two.
I would love to know the answer to this! It sounds like something that would be both possible and very useful. I assume there's a good reason why it can't be done based on how the Clojure / JVM execution model works, but I don't know nearly enough about it to hazard a guess.
> The site should ask for the language used to solve the problem and then use this as semi-scientific data for comparing "time-to-solution" for various languages.
I can't believe any valid causal inference about languages could be drawn from this, because the skill of the individual programmer at solving these types of puzzles (recognizing the patterns, knowing the number theory, etc.) would surely dominate any impact of the language itself.
I suppose you could conclude something along the lines of "newer programmers use Python more often than Haskell", but I doubt there would be many surprises there.
> business- and team-focused (read: doing what they are told)
"Doing what they are told" strikes me as the antithesis of being business and team focused - particularly the former.
A non-business focused engineer is mindlessly implementing the solutions the business asks for, without taking the time to understand the problem, motivation or mental-model of the business.
A non-team focused engineer is narrowly implementing the tasks that end up assigned to them, with no interest in what the rest of the team is doing, and not engaging with the wider team to challenge and contribute to what they are doing.