[Kototama]

> Typed languages are essential on teams with mixed experience levels

I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.

[flir]

UX really is everywhere, once your eyes are opened to it.

[bbatha]

Ill plug the "Design of Everyday Things" by Don Norman in case anyone in the thread hasn't read it. Its the classic text on design. You will never think about doors the same again.

[wesselbindt]

I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?

[nucleardog]

I would tend to agree with the author's statement there. Though less "necessary for heterogeneous teams" and more "unless your team is entirely senior/skilled".

To sum up some thoughts that have evolved over decades into something more reasonable for a comment--more junior developers are less able to develop a robus mental model of the codebase they're working in. A senior developer can often see further out into fog of war, while the more junior developer is working in a more local context. Enforcing typing brings the context closer into view and reduces the scope necessary for the developer to make sensible changes to something manageable.

It also makes it much easier to keep contracts in the codebase sane and able to be relied on. With no declared return type on some method, even with checks and code reviews it's possible there's some non-obvious branch or set of conditions where it fails to return something. Somebody might try and take a "shortcut" and return some totally different type of object in some case. In every case, it puts these things front and center and reduces the ability to "throw shit at the wall until it sort of works on the happy path" without making that much more obvious.

And once those types are declared, it saves everyone else time when stupid shit does slip through. You probably have some idea what `getProductAvailability(products)` might do in some eCommerce system. But when the actual function is implemented as `getProductAvailability(InvoiceItem[] products): void`, the foot gun for the rest of the team is... less. (Your guess as to how I know this is correct.)

In teams with good, experienced people the types are still helpful and I'd still question anyone choosing _not_ to be explicit about these sorts of things regardless of team composition. But they're much less _necessary_ in a skilled team in my experience.

[whstl]

IMO it's like scrum: if your team is good and homogeneous, it doesn't really matter much what you do: it just works. Scrum and no scrum, types and no types. It's not about having rockstars or 10x engineers, it's just about having shorthands, shared knowledge, etc.

If your team is varied or too large, you need things to help you out with organisation and communication.

(Whether my examples of Scrum and Types are the answer: depends on the team unfortunately)

[Cthulhu_]

I'm reading in it that experienced developers (be it overall or in a specific codebase) "know" all the ins and outs, types, conventions etc, whereas less experienced people cannot yet know all of that; being able to lean on good types and / or other types of automated checks helps them make more confident changes.

[bluGill]

> What is it about more homogeneously skilled teams

They are a strawman example that doesn't exist in the real world.

Companies will be in big trouble in a few years when the team retires, people find new jobs, someone dies... All of them mean that a homogeneously skilled team will exist for at most a few years if you have one. As a company you need to ensure you have a program to train in new people.

I have long believed that when someone retires you should replace them with someone fresh out of school, promoting people all the way down to fill the opening. If someone finds a new job you can replace them with someone else with similar experience, but when someone retires they should be replaced by someone you already have groomed for the job.

[cies]

I think the size of the code base also matters: bigger size = having types is more important.

There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.

[pjc50]

> More advanced typing features slow down compilation even more.

C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.

[loxs]

Even when I am alone, I have "mixed experience levels", for example I can learn something niche, write some algorithm that works in that, then 2 years later I may have forgotten it. Types are essential for me.