> 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.
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.
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?
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.
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)
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
And either learn to sharpen your knives yourself, or take them to a sharpening service. Dull knives require more force, and slip/catch more, so are more dangerous.
The trick I use for doing freehand sharpening is to color the bevel with a sharpie, that will show you if your angle is correct. You don't need a lot of stones, I just have one Sharpal double sided diamond stone, and then I move to a leather strop with 1 micron diamond emulsion compound.
Another very useful thing is an inexpensive jeweler's loupe so you can actually diagnose issues like not having removed the burr.
I looked into sharpening services in my city a few years back and they're like dry cleaners - every one was a mix of satisfied reviews and detailed "this person completely ruined my $600 knife" reviews. It was very off putting.
It's unlikely any sharpener is going to ruin your knife; at worst, they won't put the best possible edge on it. Your knife is probably just an inert hunk of steel. :)
I've watched a lot of shows about the tools used for building log cabins in the pioneer days. I don't even know the names of them, but the tool for taking the bark off the tree by pulling the knife to you as you sit on the log is crazy. Also, the one where you straddle the log and swing the blade towards you between your legs is right up there too. Yet, I can't think of any way of making them better without using power tools.
The drawknife is the safer of the two by far. It’s fairly hard to cut yourself when your whole body is moving the same direction. Similar to using a paring knife in your palm facing your thumb.
The adz however you just have to have good aim or pay the consequences!
Draw knife. As long as you are leaning instead of pulling its relatively safe. Same as its safe to pare by contracting your hand muscles instead of pushing a knife toward yourself.
Draw knives are even safer than paring knives: the handles are placed such that they're closer to you than the blade, it's extremely difficult to get your chest far enough forward that it could contact the blade without a very large chest.
You need to preheat the pan and not cook at a temperature where the oil polymerizes or the ingredients can burn. When you put something sticky in it, you need to wait a bit for the crust to form before moving it.
I can't run with full authority on Android, however. My own apps can't access my own data from other apps that I run. This is not something I can forego on my main computing device. I'm willing to tolerate it in a phone because it's just a tool; I wouldn't use a phone to store data I wouldn't mind losing.
The ability to go in and grab your own data (which you have to do using some app or another), and do whatever you like with it, such as back it up, move it, inspect it, or try to get the data into a new app because the old app no longer runs for some reason.
