The talk was entitled "Organization, Collective, Decision."
"Hope without optimism" was his first topic, based on the book of the same name by Terry Eagleton.
The grammar is distractingly bad in places and I'm not sure there's any coherent idea tying it all together, but I thought it was an interesting read. I think we need more open-ended conversations about how people organize and get stuff done. Maybe this can inspire some.
> but I thought it was an interesting read. I think we need more open-ended conversations about how people organize and get stuff done. Maybe this can inspire some.
Nice idea. In that spirit, I mention a couple of thoughts which came to mind reading TFA.
Perhaps NTSB, and hospital Morbidity and Mortality conferences, are a form of servant leadership? Of addressing not the immediate problem, but the conditions which insulated it from prevention/solution.
A pre-K science educator has suggested their students have a human right to make sense of their world - "now", not a lifetime in their future. Big hairy audacious goal. So I'd been thinking about sense-making narrative storytelling. And its overlap with work on teaching scientific dialog (eg addressing A:"X is true!" B:"I like you A, so yes, X is true!"). But I'd been thinking large-chunk narrative memes, rather than a sea of fragments in casual conversation, which seem both a likely outcome of attempting the former, and perhaps a hint at a goal. So not learning objectives, however better crafted, but a focus on shaping water-cooler conversation?
The "More like these, fewer like those" reminded me of a suggestion for design collaboration with a client - present more than one prototype, and their differences become a vocabulary for discussing the design space.
I think of groupthink as an underappreciated phenomena, so while some TFA bits addressed it indirectly, I got a feeling of unacknowledged pachyderm.
The robust systems and context-free ideas reminded me of an IMF research talk, which pointed out that it had taken years for the international development community to appreciate that you couldn't simply pick up an intervention that worked in one place, and cookie-cutter drop it in somewhere else entirely, with any likelihood of it working. I wondered where robust systems ideas are now on the getting-to-"well, duh" community education curve. And what other ideas might be plotted there.
The gist of the entire talk in essence is about promoting an alternative to Descartes rules of method and other key rational rules that have served society well for hundreds of years.
He doesn't go so far as to outright claim this but the subject matter covered clearly indicates that this is the problem he is trying to solve.
If you look at all the aspects he covers, its designed as a flawed replacement for enlightenment principles.
Personally, if you have a working system (when you subscribe and follow it), why bother creating a fanciful flawed system as a replacement that hasn't stood the test of time? Descartes has almost 400 years on this, and it still is far better than what is concretely proposed (when rightfully discarding aspects that trivially fail basic a priori reasoning).
The talk also doesn't actually cover any of the implicit structural flaws in centralized organization itself, treating it as a forgone conclusion. Overall what's promoted is super wishy washy, borderline magical thinking from what I can see. Not something I'd want to rely on for safety critical systems.
I don't think this guy is worth taking seriously. He seems to have bias against IT people, who are one of the main sources for solutions for what he proposes, their job responsibilities are largely problem solving and resilient system's design.
This clear bias, in my opinion would call into question the credibility of everything he claims. If you going to discount professionals and experts whose job is tailored towards these problems, what are you really after, its a clear contradiction that goes unanswered? It really begs a credibility question, and historically Marxists don't have a lot of credibility to begin with, they often lie by omission.
People who bash Agile or who butcher it in practice could do with a good deal of learning Snowden's material and starting to understand WHY it is the way it is. Provided they're not too stupid to understand it, which is arguable in some cases.
Agile methods, without the cult and hype, are very reasonable. They took Toyota from a producer of second-class cars for a local market to world domination.
There's real problems applying assembly-line optimizations to things that are not assembly-lines. Those problems are mostly related to the need for turning the operation into a sort of assembly-line before the optimizations can be performed, regardless of how poorly that model fits the reality of the work.
Ultimately, in a big enough org, software becomes an assembly line. Lean used right protects people and stops management from enforcing bullshit on the rank and file. But at a macro level, the only reason any dev has a job is because an end user says "I need the software to do this thing it can't already do." So how do you get it to them right with a minimum of fuss? That's Lean.
> Ultimately, in a big enough org, software becomes an assembly line
Only when badly managed, if software production is like an assembly line it means the software produced is mostly worthless because there is no freedom for anyone to diverge or improve anything, meaning they don't add any real input so you don't actually need a programmer there.
Anything that can be structured as an assembly line of programmers should be automated or abstracted so that a large group of programmers don't need to touch the same change serially (assembly line), instead that assembly line of programmers can be much better done by a single programmer that does all the serial work himself, that way you can gain the benefits of programming.
Large scale software organizations should focus on parallel workflows, not assembly line workflows (serial). Serial team workflows in software just leads to worse products.
I'd argue that assembly lines create large organizations, rather than the other way around. Large organizations are not a positive thing in software development, as it scales very poorly with org size.
You've found "the pretentious CS undergrad/junior dev" and I've found somebody who has no fucking clue what they're talking about. So we are even.
I design and implement software products from scratch for various clients. Some I own and it brings me some extra money. Been doing it since 80s. Products range - various middleware, enterprise backends, desktop multimedia applications, deep sea scanning, firmware for microcontrollers, device control and real time data processing etc. etc.
"Hope without optimism" was his first topic, based on the book of the same name by Terry Eagleton.
The grammar is distractingly bad in places and I'm not sure there's any coherent idea tying it all together, but I thought it was an interesting read. I think we need more open-ended conversations about how people organize and get stuff done. Maybe this can inspire some.