ab111111111

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.

I'd add:

4) Changes to the replacement format should be human-readable in a diff

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

Fantastic. An N dimensional error-handling space. That's exactly what Python is lacking.

Quite. Who are mere German public officials to question the rectitude of an organisation as august as Facebook?

Isn't that already the case, though? There's already a minimum wage in the US. The debate is about increasing the minimum wage, not creating one.

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.

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.

Sure. Quite. But why not try developing an AI to replace them that can make you a >5x return?

I think the Key phrase from that quotation is "thinking harder". A debugger gives you all of the programme's state as a kind of vast animation, so it's easy to start working with one thinking "Something's going wrong here, so I'll just step through the whole programmme and see when things start looking like they're going wrong". It's then easy to miss the problem due to the vast quantity of data you have to parse. Using print statements, in contrast, forces you to formulate simple hypotheses and then verify or falsify them, e.g. "I think this variable in this function is causing the problem" or "I think everything's fine with the execution up to this point". I.e. the very fact that a debugger works so well at giving you an insight into how the programmes state can itself be part of the problem: it can be overwhelming.

Not insurmountable issues, in my experience:

- Your commute is sufficiently short (I managed a 30k round trip every day at my last job. Took about 45 minutes each way.)

- You have facilities to shower and dress at work (I was lucky enough to have this, but some people who don't use e-bikes to avoid arriving as a sweaty mess)

- You have sufficient time to shower and dress at work (Say 15 minutes? Is that really a major issue? Just think of all the time you're saving by exercising and commuting at the same time.)

- You don't have to bring kids or sizable cargo (I've got a kid's bike trailer and a kid's bike seat to take my kids to Kindergarten on the way to work)

- Weather is sufficiently good (I live in Germany. I get by. When there's deep fresh snow I don't cycle, the rest of the time it's fine.)

- You're sufficiently healthy (Cycling's a great way to get sufficiently healthy.)

What major investment would be required from the city or developers to set up cycling infrastructure? Painting some cycle lanes onto the roads? Marking a few car parking places as bike parking places? That's all that cycling infrastructure really is, so it's super cheap. A lot cheaper than, say, building charging stations for electric cars.

What this seems to show is that CEOs in a particular sector often have expertise in that sector. And that Tech is currently the most highly valued sector as measured by market capitalisation. To find evidence of Software Engineers being the best CEOs overall you'd really need to find examples of them running non-tech firms successfully or examples of non-Software Engineers running tech firms poorly.

"Gambling occurs when you have a poor understanding of risk, resulting in either (1) negative expected value bets, or (2) poor bet sizing that leads to ruin." Not so. Top poker players are still gambling, but have an excellent understanding of the risks. Their skill doesn't turn them into investors. Gambling is taking a high risk bet. Whether the expected pay off is high enough to justify the risk and whether you can afford to lose the bet is a separate issue.

It's more a matter of "different languages force you to express different things". E.g. English forces you to specify subject and tense, while Chinese makes specifying such things optional.

As you indicate, Pandas is effectively another language, distinct from regular Python. E.g. it doesn't really use loops. So I think what irritates a lot of people about pandas is that they think "Cool. I can solve this complex problem in a couple of lines of Python code with pandas." then get irritated when they find that the couple of lines of pandas they need to use is "Incomprehensible pandas gibberish" instead of the familiar Python code they were expecting.

Same here. Why re-invent SQL as a weird object system?

I've also recently found that using the sqlite3 command line tool increases my productivity when doing data sciency stuff a lot. It's a super fast, super simple way of making sense of CSV data, especially for the selecting an joining operations that are so unintuitive in pandas. Once that's done, I can dump the results into Jupyter or RStudio for transformation and/or visualization.

Another personal productivity win I've discovered is using two-line python scripts to write really long and repetitive SQL commands (select count a, b, c... from huge_table where d... and e... and f...; etc.) and then running them in SQLite.