Hacker News Reader

Comment by doctor_eval | Hacker News Reader

If you’re writing database applications in a commercial environment then knowing what ACID means is part of your job.

If you don’t know that, for example, debiting one account and crediting another needs to be done inside a transaction - or the converse, what you need to do if you don’t have access to transactions - then you shouldn’t be anywhere near a database.

Fundamentals are actually important. You don’t have to know everything, but you should know the fundamentals of the field you work in.

View on HN

The important part you need to know in that case isn't the definition of ACID, but the actual transactional properties of the database you're working with. And even among developers working with databases, it varies how well you actually need to understand transactions.

And I would guess that many developers working with relational databases don't actually understand the more subtle differences between transaction isolation levels. I think asking backend developers to know the basics of transactions is reasonable. But e.g. knowing the exact difference between READ COMMITTED, REPEATABLE READ and SERIALIZABLE (and what your specific database actually implements there) might not be necessary in many cases. Though it certainly is good to be able to spot when you're about to enter territory where these differences might matter.

I agree that a backend developer working with databases should know what transaction are. But I don't really need the definition of ACID, and you can really push this question into details that are not relevant for all developers.

I agree to a point. But ACID is part of the nomenclature for relational databases. I feel that if I ask a developer what ACID means, it doesn’t matter to me if they know the specific meaning of each letter in the acronym, but it does matter that they’ve heard of the term and can explain the implications of it.

The point of jargon is to allow concise communication between experts. Knowing the jargon is part of the job.

I dislike asking what acronyms mean, as even I can't always remember the letters, although I know about the necessity of transactions and how to implement them.

Such as "I" - what is it again? "Isolation"? "Transactions are independent". Well--yes.

> you should know the fundamentals of the field you work in.

...I think that was the entire point of their post.

> I guess we would be much happier if we dared to admit that one man’s fundamentals are another man’s trivia

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.

I think the takeaway from. The article is that if this I'd the case then interviews should drop all the meaningless jargon and just ask a candidate to sketch out a solution to a problem where they would have to think about atomization of DB operations.

Reply on news.ycombinator.com