To code well, you need to be able to write well too. If your code isn't clearly written it can't be understood and it can't be maintained. Writing well isn't a "nice to have" for doing software development, it's a requirement. Yet despite this fact most coders are terrible, terrible writers. Even within the very limited literary realm of variable naming. And this lack of skills results in billions of dollars of thrown away and abandoned projects every year.
For a lot of teaching jobs, mathematical skills really aren't necessary. You don't need to be able to do long division to teach Shakespeare. You don't need to know algebra to teach French. For those professions, mathematical skills are indeed a "nice to have".
I think the individuals taking time out from their highly paid days of not bothering to add doc-strings to functions, skipping adding READMEs to new projects and not bothering to name their variables anything more informative than "data" should take consideration of these facts before posting here to say that overworked and underpaid teachers are lazy and stupid and should be required to jump through a bureaucratic hoop to confirm that they have a skill they don't need.
Healthy foods (e.g. fresh fruit and vegetables) being more expensive than unhealthy ones (e.g. McDonald's) is one of the structural incentives causing increased obesity in the US. In most countries - including Europe - it's the opposite way around. You're quite right to say that people should take care of their own health, but if you live in a place where cycle lanes will get you everywhere you need to go, there are plentiful public green spaces and healthy food is cheap and available everywhere (as I do in Germany), then staying healthy is a lot easier than if you live in, say, the suburbs of Houston.
Agree. But a lot of this is tooling though, whether its adequate and whether its ubiquitously available. e.g. you can diff two directories in Linux, which is super useful, but directories are not text files. The issue is, can the differences be reasonably represented in text formatted output.
I think a large part of the problem is that the Tolstoy "All clean data is clean in the same way, but all dirty data is dirty in its own way" riff is itself an over-simplification. In practice, "clean" just means "fit for my purpose" and "dirty" just means "unfit for my purpose".
If counting the instances of a particular string is all you need to do (and it quite often is) then de facto all data is "clean", as you can get the job done with grep. If, on the other hand, you require a relational database with strict primary and foreign key definitions and NULL limitations, then you're gonna have to put a lot more work into scrubbing.
Added to that, the more stringent the defition of "clean" you're working with, the more you're going to have to deal with trade-offs. E.g. what do you do with missing required data field values? Loosen the requirement? Add defaults? Dump those rows? And what do you do with data that makes no sense, e.g. where end dates come before start dates? What if you need to anonymize the data to meet data privacy requirements? Is rounding dates to the nearest month or year fine, or will it render the data useless?
There are recurrent problems, and recurrent solutions, and the author is absolutely right to say that more open source work should be done in that area. But due to complexity and inconsistency of the definitions of "clean" and "dirty", we will unfortunately never get to the point where we just feed some library the path to an arbitrary dirty data directory, press enter, go off to grab a coffee and come back to find our freshly cleaned data waiting for us.
I guess it is conceivable that you could take 1000 dirty input files and their cleaned output and use this as a training set for a ML-power data cleaning system. But:
Sure. You could and should do that if you can. But, as you say, it'll still only work for one narrow definition of "dirty" and another, equally narrow, definition of "clean".
I think the author's underlying point is that all of the decentralised applications she's talking about rely on their having a large number of users communicating with one another in order to do what they're supposed to do, and that decentralised systems often perform poorly in terms of getting enough users for them to achieve that goal.
Imagine you came up with a technically superior version of email, and it functioned technically perfectly, but you were unable to convince anyone else to use it. Sure, it would "work" technically in a narrow functional sense, but it wouldn't "work" in terms of doing what it was actually designed to do. My taking LSD isn't really affected by other people doing so or not: it's a private thing. But my sending an email is: it's a network interaction.
The author's claim is correct in the sense that, if you hold a party and no-one comes, the party didn't really work.
I think it may be more a "monolinguals are hard to understand in a lingua franca situation" issue. It just happens that a lot of English speakers are monolingual compared to speakers of most other languages.
When you learn a new language, particularly as an adult, you learn that you have limitations in its use and to be able to accept and work around them. You learn that that's nothing to be ashamed of, because you put in a hell of a lot of work and can now function in what used to sound like complete nonsense to you. You learn to prioritize keeping things short and simple to minimize the chance of your being miss understood.
In your native language, amongst native speakers, everyone's so skillful at communication that there's often more of a focus on how something is said than what is said. I.e. it's so clear that other speakers will understand a speaker's basic "I want to have this done by tomorrow" message - however they formulate it - that they often put more focus on other issues, such adding jokes or word-play, ensuring the correct level of politeness is used or communicating the nuisances of their current emotional situation. To other native speakers, that results in a richer signal, one containing more information which costs them no effort to understand and which they can filter out or pay attention to as they wish. To a non-native speaker, that additional information is just noise: like listening to a message over a bad radio signal. It costs them a lot of effort to attempt to understand it, they often fail in doing so and it gets in the way of their comprehendig the core message. They just want to hear "I need it by tomorrow morning", not "If it isn't too much trouble, is there any chance we could get this done by tomorrow?"
A monolingual can get this in the abstract, but it's easy for them to forget. Someone who's gone through the millions of minor embarrassments, humiliations and triumphs it takes to master a second language is far better disposed to remember it and act on it in practice.
The whole point of a minimum wage increase is that it will increase all restaurants' wage costs to the same degree, at the same time. Meaning that going "down the street", potential diner's will find that all restaurants' prices have increased equally. So the business threat isn't that American consumers will abandon "Dale's" in particular for some other restaurant. It's that they will choose to eat at home instead of eating at a restaurant, or that they will order less food when they do go to one.
"it will increase all restaurants' wage costs to the same degree"
In an ideal world full of law abiding citizens, yes.
In practice, restaurants that cheat are going to win.
I live in a country that has a lot of regulations in the hospitality sector and yet the "paid under the table, not officially employed here" phenomenon is everywhere.
There's a whole world of outsourcing shouting angrily at people over the phone. That's what call centres are. And their workers normally cost a lot less than CEOs.
For a lot of teaching jobs, mathematical skills really aren't necessary. You don't need to be able to do long division to teach Shakespeare. You don't need to know algebra to teach French. For those professions, mathematical skills are indeed a "nice to have".
I think the individuals taking time out from their highly paid days of not bothering to add doc-strings to functions, skipping adding READMEs to new projects and not bothering to name their variables anything more informative than "data" should take consideration of these facts before posting here to say that overworked and underpaid teachers are lazy and stupid and should be required to jump through a bureaucratic hoop to confirm that they have a skill they don't need.