[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)

[bluGill]

In my experience: Too large is any team larger than 10 people or any code base with more than 10,000 lines of code. Both of those would be considered tiny by most in the industry.

[whstl]

Oh, you are definitely correct about 10 people being too many. For me I think the magic number was 4 or 5.

About 10k lines, I really never stopped to think but I'm gonna guess you're correct on that too.

[bluGill]

The numbers I gave are not exact. Depending on details that I don't think anyone entirely knows. Sometime 1 person is too many (generally implying a bad programmer), while other times you can get a bit over 10 if you have strong discipline. Likewise strong discipline can get you to 100k lines. Really what this is about is how much pain you are willing to put up with. 10 people and 10k lines of code are good round numbers to work with.

[default-kramer]

Hard disagree on the 10kloc limit. At a previous job, I maintained and enhanced a 50kloc monolith (written by someone else), usually by myself. My productivity was very high. At my current job, we've split a codebase that should be about 50kloc into more than 10 separate repositories; everything is still just as coupled but it's much harder to reason about and refactor. My productivity is much lower.

[thot_experiment]

Agree, people underestimate the cost of interfaces that don't sit exactly where they need to sit (which is almost always the case)

http://number-none.com/blow/john_carmack_on_inlined_code.htm...

[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.

[naasking]

Less experienced devs iterate on something until it looks like it works, not realizing the footguns they may have embedded. Static typing removes some footguns and provides documentation for the next unfortunate soul to look at this code.

[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.

[cies]

I agree. But the nice thing about types is that they are not an afterthought, but more a "pre thought". TDD tries to make testing a pre thought...

[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.