They don't even know the fundamentals

40WPM is fine, and far beyond actual hunt and peck.

But I have encountered one IT professional (not a programmer) who despite being in the industry for 20+ years, could only manage about 15WPM, if that. His style seemed to include legitimate hunting for the next key, and only two fingers.

At that speed it was starting to become problematic: It was painfully slow to watch him do anything or help him with a problem.

Not an absolute deal breaker, as long as such a person is good at their job and is efficient with what they type (taking advantage of copy/pasting or scripting), it's workable.

> It turns out my day to day work doesn’t require deep knowledge about database internals and I can mostly treat them as a black box with an API 2.

Because of such attitude of the previous dev team my client ended up with DB integrity ruined. Previous guys somehow didn't know they should use transactions when updating/deleting stuff in the DB, because hey, it's just API you call, who cares of mambo-jumbo happening behind the curtains, right?

I myself had a similar fuckup with MongoDB a decade ago, because I used it "because it's fast", but failed to read the small letters, and wasn't aware that it achieves that speed by buffering the data for async save, and so has no guarantees it will actually be saved at all. So I lost a lot of data when traffic suddenly jumped, and since those were affiliate clicks lots of people got very pissed about not getting paid, and it almost ruined both my client's business as well as my own, as it was our core client.

Lack of understanding of (or even caring to know about) DB internals is also why like 90% of projects I've seen has wrong indices, or often no even a single index set at all. Because, hey, it's someone else's job to think about it, but in reality budgets are limited and team don't have a dedicated DBA or even a capable devops person to notice it, and it just ends up in the production like that.

So, in summary: no you don't need to know every in-and-out of every technology out there, no one can do that, but there's a valid requirement that one has to be familiar to those that they actually use - at least those that can seriously bite one's ass and cost a lot of money. And all DB related stuff is very much like that, that is probably the most critical part of the whole system, so no, it's definitely not a black box.

Does documentation factor into this?

If I can touch-type at 120WPM, then I can churn out a great deal more documentation per unit time than another engineer that can only type at 40WPM. It's less burdensome for me to document well, to write expositional documents and to communicate regularly than my colleague that needs to budget their typing more carefully.

While I might not be bottlenecked when working on a tricky piece of code at 40WPM, I'll likely be bottlenecked elsewhere often.

Youre right. Im probably lucky to not experience any wrist strain.

Regarding speed - it didnt prevent to be TOP1 at university in typing contest :)

I don't see the connection between your reply and the linked article's content. A major point is already made right at the start when an ACID definition is quoted from a book - which makes it clear that that term is too nebulous and, in conclusion, that simply regurgitating some definition is not helpful in practice.

On the other hand, if you are actually able to design for all those complex points you may still not have one short definition to quote available, which would not speak against you at all. Not having a short definition for ACID to quote may happen to both real experts as well as people who really don't know anything. Because for real experts that definition is too simplified to be of any use.

I saw similar issues a lot in school and in academia, when having to answer some test questions: When you actually know a lot more you may actually get many answers wrong, because the one asking used a much simplified model (and therefore more inaccurate than yours) as basis for creating their question. For example in biology, there are some key tenets, but when you go deeper you learn about all the additional quirks and exceptions. Using the simplified tenet an answer to a question "can this or that happen" would be never, but for someone who knows a lot more that answer would be wrong. As an expert, you no longer use that simplified model you learned early in school.

Example blog post showing the world is more complex than the simple definition: http://www.bailis.org/blog/when-is-acid-acid-rarely/

That was the point of the article, as shown by this example quote:

> How many similarly vague “fundamentals” we have floating around us? Plenty: RESTful, MVC, SOLID are the first things that come to my mind. If you start a discussion about the meaning behind those terms, you will find yourself in the middle of a food fight where everyone will have a slightly different opinion and no consensus will ever be reached.

All I have top do is read HN whenever such a topic comes up. It usually ends up with a lot of back and forth of people who are all experts but have a slightly different angle, and the initially clear definition falls apart when you read the discussions.