However, I prefer statically typed languages like Scala, as it is easier for me to compensate for lack of internal discipline with external constraints.
They're both vaguely accurate but break down if you try to credit them with too much explanatory power (as Yegge does, IMO, but Oakes doesn't seem quite as reductionist).
I think most people can say pretty accurately whether they're in the "open for business by Tuesday" model of software development or the "700 years and undreamt-of threats" model... But if your product becomes a surprise hit, that's when you refactor your chaotic bazaar into a clean, legible, highly maintainable cathedral.
- play-clj, a Clojure game library
- Nightcode, an IDE for Clojure
- Nightweb, an anonymous P2P social network in Clojure
and (non-Clojure) - SolidOak, an IDE for Rust
Also, his "Making Games at Runtime with Clojure" talk  is great.
The only downside of that was it made sometimes harder to figure out the error. When you get run time type error, you can do the traces on the values and see where it happens more easily. In case of static typing error, you cannot even start the program. But perhaps this just requires some better practice.
And I also experienced the "when it compiles, almost correct" proverb from Haskell community.
The other thing that converted me to Haskell from Lisp was that I learned (theoretically, so far) about how to write interpreters using free monads. And you get type checking with it.
I'm using F#, and without a IDE that tell me what kind of crazy type is the code I'm looking right know I can't function.
I have used delphi (love it!) and write the types is so minimal, and the benefit of clarity are great. I use a lot of python, I'm used to be unsecure about what exactly the types are. I use F#, and I'm even more unsecure about it. Is kind of infurating that the compiler know what the types are, but all of that is hidden to me!
P.D: Type-inference is the thing I like less from F#. All the rest is great to me (Pattern matching, AGDT, etc).
I wish the editor show me the types in read mode but I can write without type all in write mode. So, I write "a + b" and then when move out the line, the editor show "a:int + b:int" or something like that. That could truly be the best thing about the 2 worlds.
My characterisation of the two types would actually reverse the top-down/bottom-up labels: type-A's seem to be dithering around in the details, trying to assemble something larger, while type-B's get the big picture, but loose focus as they zoom in on the details. In practice this explains the outward appearance: type-A's obsession with getting the plan right (because they are chronically lost), and type-B's rapid tinkering (because they never know if their crazy idea is going to work or not).
The two types struggle to connect: type-A just sees the B as a big mess, and type-B sees the A as technically correct but missing the point entirely.
The reason computers are a revolutionary productive technology is that when you put them together on a team they don't do what you would expect and do the wrong things badly but instead do the right things well.
I don't know how to use that story to write better Clojure, though.
See, e.g., game engines vs. Lua scripting, or the LAMP stack vs. PHP scripting, or the implementation of framework DSLs like Rails vs. their usage. Type A people write libraries and generic servers; Type B people write apps by consuming and wrapping and configuring and composing libraries and generic servers—writing the classic "glue code."
I think a lot of the misshapen cultural dynamics in most software projects are the result of Type A people thinking its their job to implement policy (in the engine), and Type B people thinking it's their job to implement mechanism (in the app.) It works best when these people aren't on a team, but instead have a clearly-defined idea of where their responsibilities end and passing the buck begins.
I compare the process of creating software much like pottery when you start out with clay it's not clear what the end result is going to be. But as you play around with it something forms, and you impose more structure and clear cut features with refactoring.
type b coders like us get a lot of shit for eccentric decisions that ultimately lead to breakthrough ideas or features but type A coders is almost always dominating with logic and aggression I see tensions between developers.
If what the article says holds true, I would say Type A coders are more for maintenance and Type B coders are the visionaries. Type B is the engineer that gets paid millions for writing MVPs as a early CTO while Type A engineers tendency to compete on everything leads to burn out and lower salary. Likewise Type B would be horrible in a corporate environment where as Type A would do well.
I do agree with you that the tendency to compete to be the most "right" is a problem amongst programmers, but I don't really see that it fits into this whole (contrived, IMO) "Type A" vs. "Type B" thing. I've seen plenty of bikeshedding amongst the organized and the disorganized alike.
Almost early on in any startup phase, you want a type B to quickly build MVP without drama and then hiring type A to refactor it.
I've seen a startup get all worked up about structures, spacings, unit tests when they don't even have a customer yet, can't ship fast enough because of all these bottlenecks introduced by Type A architect.
In large corporation Type A would thrive where as the Type B wouldn't so I just don't see why you take what I said to the heart.
The truth of the matter is that knowing when and how to build an MVP quickly without wasting time on the wrong things and knowing when and how to create reliable and maintainable software is all part of your job as a software developer. Choosing one or the other as "that's just how I am" is shirking responsibility.
Like the article says nobody is right or wrong. I just simply put the case out there that one personality is a good fit for different stages of the company.
I will also very much question your visionaries/maintenance distinction. Many dynamic languages today are influenced by technology developed in academia. This is because the "type B coder" you are speaking of lacks the theoretical foundation to build sound abstractions that are proven to not break.
I would describe myself very much as a "type B" personality - I'm completely disorganized, messy and lazy. I've event gotten into (physical) fights with flatmates over this.
And precisely because of this, I'm choosing technology that takes away all the rigid bookkeeping and context switching that is needed when writing anything more complex than a basic Bootstrap/Angular/whatever bullshit CRUD app.
This is because refactoring is a lot harder in a language without structure. I would never dare rip out the base data structures and replace them with something completely different in a project with more than 2kloc in a language without types. While in a logically sound language I do that daily and don't even care - a perfect fit for my "type B" personality.