They don't even know the fundamentals

&gt; 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.<p>Because of such attitude of the previous dev team my client ended up with DB integrity ruined. Previous guys somehow didn&#x27;t know they should use transactions when updating&#x2F;deleting stuff in the DB, because hey, it&#x27;s just API you call, who cares of mambo-jumbo happening behind the curtains, right?<p>I myself had a similar fuckup with MongoDB a decade ago, because I used it &quot;because it&#x27;s fast&quot;, but failed to read the small letters, and wasn&#x27;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&#x27;s business as well as my own, as it was our core client.<p>Lack of understanding of (or even caring to know about) DB internals is also why like 90% of projects I&#x27;ve seen has wrong indices, or often no even a single index set at all. Because, hey, it&#x27;s someone else&#x27;s job to think about it, but in reality budgets are limited and team don&#x27;t have a dedicated DBA or even a capable devops person to notice it, and it just ends up in the production like that.<p>So, in summary: no you don&#x27;t need to know every in-and-out of every technology out there, no one can do that, but there&#x27;s a valid requirement that one has to be familiar to those that they actually use - at least those that can seriously bite one&#x27;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&#x27;s definitely not a black box.

I&#x27;ve found bad interview questions fall into one of three camps:<p>1. The interviewers aren&#x27;t subject matter experts themselves but are hiring managers, so they&#x27;ve taken their questions from someone else.<p>2. The company gets far more good candidates apply than they can hire, so the process is less about removing bad candidates and more about having some arbitrary way of whittling down good candidates.<p>3. The interviewer is trying to prove how clever they are or the company is. Sometimes for their own ego but more often because they think it might make the company more attractive to work at.<p>If there is a theoretical question I&#x27;d normally Google &#x2F; DDG instead of memorise then I&#x27;d usually be honest in the interview and say &quot;it&#x27;s something like xyz but in truth this is something I double check these days as, pragmatically speaking, it is not a problem that comes up frequently. However it is something I have done before [cite example]&quot;.<p>If the questions is asked because of reason 1 or 3 from above, then usually they&#x27;re happy with that answer. If they ask it because of 2, well as much as I might disagree with their interview process, I&#x27;m still not the candidate they&#x27;re looking for. So we still part of good terms.

&gt; “Yes, every programmer should know how their hardware works as one cannot write an efficient software without that knowledge 4, and I wouldn’t be able to do my job if I didn’t know anything about computer internals, yak, yak, yak…”<p>I agree that you don&#x27;t need to know anything about von Neumann Architecture and the likes in order to be a Web Dev.<p>But I wouldn&#x27;t want to hire someone who doesn&#x27;t have basic knowledge about data structures and runtime complexity. It&#x27;s just too easy to have something work fine in development, but choke in production due to accidentally quadratic behaviour.

This promulgation and advocacy of laziness and know-nothing-ism is frightening and all too commonplace nowadays.<p>The ACID example was a bad one, granted, but everyone seems to be giving up after identifying that. I also think that this post is not about interviewing. I am much more concerned with the line the author takes about knowing how a digital computer work is even necessary. How have we arrived at this point?<p>As an example, how seriously would you take an aircraft flight controls software engineer who willfully chooses to never learn how an airplane flies? What if they just claimed that their sole responsibility was to take flight requirements from “people who know how airplanes work” and implement code? Knowing how horrific the results of this attitude is in even low pressure business situations, would you get on the plane he designed the software for?<p>People who live by and spread the idea that one only need know the things he or she is ‘required to know’ are dangerous for engineering organizations. When something goes horribly wrong, your mission critical system crashes, when you get dragged before the higher ups to explain the situation and fix it, the excuse ‘I don’t have to know how this works to do my job’ simply won’t fly.<p>People have lost all respect for the pursuit of excellence. Ask yourself who you would like to have on your team: someone who stops at learning the bare minimum to get paid and inevitably ruins the integrity of a product or someone who continually pursues getting better at their job and accelerates the people around them? Would you rather work with someone who values knowledge or someone who doesn’t?<p>I think it is drastically foolish to defend the toleration of those who aren’t even willing to learn basics like how a computer works in the name of inclusivity, utilitarianism, or egalitarianism.<p>Furthermore, I know a slew of extremely bright, tenacious, and committed young people who are ruthlessly pursuing excellence in engineering. If given the chance and enough time they will easily outperform, outwork, and surpass anyone who adheres to these lazy practices. If you do think this way and don’t want these kids to take your job then I suggest you buckle down a bit and learn some basics.

Oh for fucks sake, every month this topic comes back. It honestly doesn&#x27;t matter if the fundamentals are useful or not. What gets me is that programmers want to be hired by top-tier companies and earn massive salaries without putting a single drop of effort into actually acquiring the knowledge that justifies that position.<p>Can we just collectively swallow our privilege and stop whining that an employer is asking for proof that you&#x27;ve actually put the effort to be an engineer before they dump a river of money onto you? Look at how lucky you&#x27;re before whining that the world is unfair, and shut the hell up about fundamentals.<p>The interviews surely aren&#x27;t perfect, but the constant whining is ridiculous. Why not just study it and be done with it already?

The Feynman principle applies - it is important to know the thing and not as important to know it&#x27;s name. In an interview, find out if the person knows them thing or can work it out.

Most of your time isn&#x27;t spent in fundamentals though. I find a lot of my time is spent looking up some kind of best practice, or discovering what libs other people are using for a problem.<p>Also, things may be fundamental, but not everything is built up from fundamentals. Maybe math is the best place to look at this. When you go to school, you just do it. Number lines, equations, calculus, matrices. Even through the engineering course I did, which had all sorts of advanced topics, nobody mentioned ZFC or Peano or Cantor or anything like that. And while it&#x27;s true that if you dig under the stuff that you get taught there&#x27;s a whole interesting world, it doesn&#x27;t seem to stop anyone from using math.<p>With coding, a lot of it is having the right attitude. Something&#x27;s broken, I&#x27;m going to try to understand why and what other people have done to fix similar issues. There&#x27;s a resourcefulness that beats classroom teaching in terms of usefulness. You want that person who is capable of understanding everything that might happen, what he needs to do to fix it, etc. That person is never going to know or have heard of everything to start with, but they can deal with things when they happen.<p>But of course it&#x27;s easier to test whether someone has heard of this or that thing. Perhaps this is why senior devs find it easier to get a job than junior ones, employers are more likely to think that they can work through issues.

I will still never understand why I was asked to code an implementation of a binary tree for an interview once, something that is usually left to those who implement standard libraries or similar low-level needs, for a job that was basically writing user interfaces.

I mean sure, yes, there&#x27;s also programmers out there who&#x27;ve been working for years and look at me like I&#x27;m speaking in tongues when I talk about closure.<p>The author&#x27;s casual arrogance about &quot;pixel pushers&quot; only caring about &quot;hotdog stand colors&quot; is just as damaging to the profession -- as it infects the hardest part of getting things right most of the time: teamwork.

“Atomicity, something, something, Durability?”<p>My exact response after reading the first quote. It is indeed fundamental, and something I am mindful of with every database query I execute. But I haven’t thought about the exact definition and its mnemonic in over a decade.

&gt; There is another fundamental that is ignored by a lot of computer users. I think everyone who spends a lot of time behind a computer should learn how to touch type, since typing is still the main way of interacting with your computer.<p>I sort of agree, but anyone typing out code at 120WPM isn&#x27;t programming, they&#x27;re writing. Programming is an intellectual activity, not a physical one so learning to touch type is worthwhile but might only gain you a few minutes a day of productivity over someone doing 40WPM in a home-grown hunt-and-peck style of typing?

I like the Zoho strategy of just hiring high school kids and training them - <a href="https:&#x2F;&#x2F;m.timesofindia.com&#x2F;india&#x2F;this-man-is-also-driving-one-of-indias-most-profitable-unicorns&#x2F;articleshow&#x2F;85171268.cms" rel="nofollow">https:&#x2F;&#x2F;m.timesofindia.com&#x2F;india&#x2F;this-man-is-also-driving-on...</a>

I feel that this is a perfectly good interview question for a so-called &quot;full stack developer&quot;:<p>&gt; Let&#x27;s turn to databases now. Can you explain ACID to me?<p>I&#x27;m not saying that the original article on RoyalSloth was wrong, exactly. It has to do with the way the interviewer approaches the question. For instance, for that full-stack developer I would be PERFECTLY satisfied with an answer that went like this:<p>&gt; Hmm. Well, I don&#x27;t remember exactly what the letters stand for. Atomic, something something. But look -- some databases, like MongoDB, can sometimes lose data after it has been &quot;committed&quot;. Other databases, like DynamoDB, can read just fine from one table but they can&#x27;t guarantee some basic invariants when reading from multiple tables at once. And some others, PostgreSQL and most &quot;relational databases&quot; fit in this category, jump through hoops (I don&#x27;t know quite how it works) to make certain that what you see is always consistent.<p>If I were hiring someone JUST to do front-end web design then this wouldn&#x27;t be relevant. If it&#x27;s someone more junior then the above sentiment but without the ability to name specific examples would be fine. But I don&#x27;t want to hire someone to work on interfacing with the database unless they understand it to at least this level.<p>If I were hiring for a database specialist I would expect a much more detailed explanation.

&gt; For the majority of programmers out there, something being RESTful means that you can feed it chunks of JSON over HTTP. The minority, who have spent some time reading about it, will complain that it’s a design principle defined in the Roy Fielding’s thesis and it has nothing to do with JSON or HTTP 3. How many of you have actually read his thesis? All of it? No skipping?<p>I&#x27;ve been railing about this for years. Please stop calling it a REST endpoint. In 95% of the cases it is a custom HTTP endpoint and that&#x27;s it.

Knowing fundamentals <i>is</i> important. It is simply part of the professional culture, or part of what they sometimes call a degree of professional “maturity.” A programmer who is not aware of the fundamentals will always find a way to write bad code.

Don’t ask questions that can be answered with a web search.

Author is not completely wrong, but I don&#x27;t like this attitude of celebrating ignorance. I agree we shouldn&#x27;t judge others who happen not to know what we know, but IMO it&#x27;s likely that knowing this concept at a deconstructed level will be helpful to most devs at some point in the future. The ones who don&#x27;t know it won&#x27;t even know it would have helped them, because that&#x27;s how knowledge works. And that&#x27;s why it&#x27;s important to celebrate knowledge, not ignorance.

If you’re writing database applications in a commercial environment then knowing what ACID means is part of your job.<p>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.<p>Fundamentals are actually important. You don’t have to know everything, but you should know the fundamentals of the field you work in.

In a google interview I explained CAP theorem using the speed of light. The interviewer didn&#x27;t understand. He clearly wanted me to regurgitate the official definition.

The author is talking about hiring interviews like it’s some kind of multiple choice test. Interviews should be more like essays. Of course it is not that important that the interviewee knows the exact definition of ACID but they should certainly know what it is about. Knowing about ACID and the problem space it comes from enables people to think about problems that let to the ACID concept as a solution to said problems. It shows that the interviewee might know enough to look things up and might be capable of selecting the right answer in the reference material&#x2F;search engine results. Knowing the exact definition of ACID and nothing else means that somebody can memorize things which is useful but not useful on its own. You want people that can find a solution and have an somewhat informed opinion about it, not people who can just memorize things.<p>So asking about ACID is a fine thing, but expecting a text book answer is silly.<p>Edit: ivanhoe said it better in their post and I changed my phrasing to be less inflammatory. (My point of different hiring mind sets on different continents is not the point.)

Yes, you can write some storage solution or yet another database without knowing ACID terms but you will still end up somewhere in the CAP triangle. Using common terms like these makes it easier to communicate with other engineers and makes it more obvious that a lot of things have already been solved and perhaps there’s a library that you can use. In the same spirit you should not write your own cryptographic algorithm and for example you could develop an API that is not RESTful but it’s more interoperable when you are using standards and prior knowledge. I personally would not hire a guy to work databases if he insists on not having to learn about ACID.

&gt; Yet, despite coming up with a distributed archiving system that works in production, I wouldn’t be able to explain from the top of my head what the ACID term means.<p>You could probably talk about the important properties of interactions with a datastore well enough to please a reasonable interviewer. Why assume they aren&#x27;t reasonable? I really hate the trope of, &quot;XYZ came up in an interview, and therefore I assume the interviewer is making hiring decisions according to a such-and-such rigid criteria I imagined when I went home afterwards.&quot;<p>(The conversation with &quot;Joe&quot; of course is imaginary, because you wouldn&#x27;t already be started with interviews if you hadn&#x27;t talked about how you were going to evaluate candidates. If this conversation happened in real life, the blog post would be about planning for interviews and not going rogue with your interview agenda when you&#x27;re part of a team process.)<p>Interviews are designed to figure out where a candidate is with their knowledge, all the way from &quot;they don&#x27;t know anything about databases&quot; to &quot;they can write a little bit of SQL with help&quot; to &quot;they have 10 years of experience with the database we use for our OLTP, and our expert had a great conversation with them about the technical details of a quirk that bit us in production last week.&quot; Depending on the position, these might all be acceptable levels of knowledge for a position, not to mention that companies are often hiring for multiple positions, not all of which have been publicized yet, and are often open to redefining a role for the right candidate.<p>Every candidate has their own idiosyncratic mixture of strengths and weaknesses. Candidates have a hard time believing it, but a hard or unexpected question is usually probing for strength, not weakness. If interviewers only asked questions that a minimally qualified candidate can answer, they would miss your strengths and undervalue you as a potential hire.

Once upon a time I was sitting in a chemistry class at Rose-Hulman, and the professor proceeded to use all the formulae we had learned through the trimester to explain how a semiconductor diode worked, then proceeded to explain transistors, from a purely chemical reaction rate basis.<p>I was in awe... and for a while after that, I thought I understood the basics of electronics.<p>Last year I learned how tubes work, especially when slightly gassy, and thus ignitrons, etc... turns out I didn&#x27;t know how all electronics worked.<p>There is always another layer to learn about. The ARP address layer of the network stack, for instance.<p>The Unicode layer they added between my days as a Turbo Pascal programmer in MS-DOS, and the present. (Which apparently can be used to hide trojan horses)<p>Always, always, always another layer.<p>The best we can do is to try to understand all the layers that definitely affect us, and a layer or two more as insurance (or just because it&#x27;s cool to know)

I think the example is very poor, it sounds like a atraw man argument.<p>Asking about fundamentals in an interview is, surely, a given? I don&#x27;t necessarily need everyone to know everything about everything but if I met a dev who didn&#x27;t know some software principles or a DBA who couldn&#x27;t explain ACID to at least a basic level, why would I want to employ them? Because they tell me that they just work it out when necessary?<p>I&#x27;ve cleaned up too much code from people who think &quot;just use an array&quot; or searching through a massive list because they don&#x27;t know how dictionaries work.<p>The interview questions sound more than reasonable and then the OP tries to destroy this by saying that not everyone knows all the details of everything which is not what most people would call questions on fundamentals.

Yeh, um, no thanks. I&#x27;ve had to deal with too many race conditions, random data loss and week-long-debugging of locks to brush off the &quot;fundamentals&quot; as nice-to-have.<p>It doesn&#x27;t matter if you&#x27;re a frontender or writing a shell script to automate something. If you don&#x27;t understand atomicity, race condition, locking, etc., not only are you going to shoot yourself in the foot and tear your hair out when shit breaks randomly, but you&#x27;re going to subject the poor souls who come after you, to unnecessary suffering.<p>One doesn&#x27;t get good at these fundamentals by getting a Comp. Sci. degree. All of it can be learnt in a few days. What&#x27;s important is to keep evaluating your code and design all the time against it to ensure you&#x27;re not building on crooked foundation.

In my experience there is not much to know about the ACD parts of ACID, because they&#x27;re just guaranties that are obvious to want and which will naturally make your life easier.<p>The I (Isolation) part is the one you&#x27;ll need to understand whenever you scale up to a point where concurrency starts to become non trivial in your product, mainly because there are multiple levels of isolation, which each provides different guaranties, and you&#x27;ll need to understand what level your database uses and what it means for your application.<p>As for the overall point of the article, it&#x27;s just a question of scale. The more you scale the more you need to cut through the abstraction to understand what the hell is going on. Hire accordingly.

I feel like the big issue in the provided example is not so much the fundamentals, but that the &quot;fundamentals&quot; in this case is just buzzword trivia. Maybe a better question would be to ask about atomicity and isolation specifically in the context of a DB?<p>For example, to me a fundamental for C++ development is knowing the difference between an std::vector and an std::list. Can you really be an effective C++ programmer without knowing that?<p>Yes the field is vast and lists and vectors can mean different things in different contexts, but you&#x27;re applying to a C++ development job so I expect you to know some basics about C++ specifically...it doesn&#x27;t seem that unreasonable to me.

The fundamentals are important. In my field of engineering (not software) ignorance of the fundamentals means not knowing how to properly run studies, not being able to accurately make recommendations, not understanding proper cause and effect, not knowing the relevancy of the various settings of the industry standard software...etc etc. It&#x27;s really hard to find that in new graduates and there is virtually no decent training material. It typically takes 5+ years for just minimum competency, but over a decade before someone begins seeing how everything fits together. Is that common elsewhere?

The interview style that requires lots of prep studying and leetcode memorization probably does produce the desired result. Workers that will spend non-work time on arbitrary company activities of questionable value.

This is basically because interviewers need to properly advertise the level of depth they want in a role. It&#x27;s unfair to ask for each engineer to be in the top 5% of engineers everywhere -- not every engineer can be -- but there are roles that don&#x27;t require such depth.<p>But interviewing in general is tough (I&#x27;d go so far as to say it&#x27;s a shitshow) and there&#x27;s lies on both ends -- companies and managers and folks on the inside just want the best of the best -- and candidates just want a chance to get in the door -- the incentive to embellish is too high.

I think this discussion contrasts two opposite types of &quot;fundamentals&quot;.<p>Some &quot;fundamentals&quot; sit at the base of a knowledge pyramid. If an OS developer doesn&#x27;t know pointers, there&#x27;s no easy fix for that. You want someone with years of experience building things on top of pointers.<p>But other &quot;fundamentals&quot; are more like things that are used very commonly and thus one expects that experts would be familiar with them, but they sit on top of knowledge pyramids. It&#x27;s not hard for experts to pick them up.<p>I think this lens can help clarify a lot of these discussions!

My company went public and was acquired, all while doing basic database shit hilariously wrong and just strapping in memory caches everywhere instead of using indexes.<p>We have two caches and we really just needed to use the dB in a not criminally bad way.<p>But the market didn&#x27;t care and the people who did the abuse are now director or architects or manager level engineers at other (good) companies.<p>There&#x27;s some reality that knowing this stuff matters but it honestly doesn&#x27;t for a huge number of tech startups, at least in this market.

I have gotten to where is someone asks me to do a linked list or recursive tree search I just end the interview right there. Ask me their strengths or why a balanced tree is useful, awesome. It&#x27;s fine I hope they have find the right candidate, but as an embedded person I haven&#x27;t had to write those in decades and if I need to I&#x27;ll look it up. Sorry I don&#x27;t have everything a CS grad has fresh in his mind or something that you write daily but most of us don&#x27;t

To me non-ACID means you can never use any logical reasoning to have an idea of what there is recorded in your database at any given moment. ACID means you execute a piece of code in a transaction and if something goes wrong it fails altogether returning you to the pre-transaction state. Am I wrong?

&quot;Yet, despite coming up with a distributed archiving system that works in production&quot;. The thing is, did he? Really? I know plenty of people who get things into production and by working they mean, doing something that appears like what it&#x27;s supposed to do. I usually find these are the people who blame everything else for why it&#x27;s not working. A red flag is usually the phrase, &quot;X isn&#x27;t ready for prime time&quot;. The translation for that is, &quot;I found something that I couldn&#x27;t figure out and probably will never figure out so you better let me choose something else&quot;. These are the people who habitually bounce around from framework to framework. Oddly the more cutting edge it is the better. That way they&#x27;re on the cutting edge so you need to expect problems, better than everyone else, and because they&#x27;re better than everyone else you need to listen to them when they tell you, &quot;It&#x27;s not ready for prime time.&quot;

I have 10 years experience and an MS. It&#x27;s possible I would fail these fundamentals (I have in the past). At my company, we don&#x27;t talk using big words for tech. This is mostly because we would just end up translating it for the business folks in the room.

Beginners tend to obsess about the precise definitions of terms. Possibly because a lot of teaching is about learning definitions (because it is easy to test) or perhaps because in subject like math the definition really is the meaning.

&gt; not every programmer is dealing with performance issues as part of their job. Some has also specialized in writing GUIs and are more concerned with the user experience and making the user interfaces pretty.<p>This is a really important point that we don’t talk about enough, because everyone gets uncomfortable and feels judged. But I can’t help myself, and I think there’s a lot more to dissect here.<p>I think programming is slowly bifurcating. We’re growing into two disciplines.<p>One discipline requires deep systems knowledge. A CS degree is recommended and if you can’t reverse a binary tree on a white board then you won’t be able to read our code base. Developers in this camp work on rendering engines, Vulcan drivers and schedulers. They spend lunch telling stories about that one time we wrote a game engine in J. Or arguing about type systems.<p>The second group makes most of the software (measured by lines of code). And almost all the software humans actually interact with. They spend their time working around weird safari quirks, arguing about electron, and enjoying the sense of ease and mastery that comes from staying in a single ecosystem for a decade. Getting better at their job looks like getting better at talking to users and customers, making on point estimates and making sure the team releases on time.<p>The part that gets all of us in trouble is that the first skill set is (arguably) harder - and thus much more prestigious. Everyone wants to be seen as an electrical engineer, not an electrician. So people write “software engineer” on their resumes. And then cry foul when they get assessed as a member of that first group. “I’ve never needed to know about red black trees in my career. It’s stupid for anyone to ask about it in an interview. Everyone just crams leetcode. JQuery isn’t flashy but it works and I can solve real problems with it. Hire me you fools, and I’ll show you!”. They’re sort of right. We’re just collectively confused about what sort of job they’re being hired for.<p>I think this confusion hurts everyone. I once wore my fancy engineering hat at a normal consulting gig. I coded up a complex solution to a tricky problem they had and called it a day. After I left, nobody on the team could understand or maintain some of the code I wrote. That caused huge problems for my client after I left. I think they might have regretted bringing me on board at all.<p>But we can’t even talk about this because we don’t have the language. We treat application developers like they’re just junior, in training versions of deep CS systems engineers. But practicing building kick-arse iOS apps doesn’t make you magically good at data structures. And vice versa - doing performance work doesn’t make you good at working with clients. (Ask me how I know). The majority of professional programmers do plumbing &#x2F; user facing software. We need to destigmatise this stuff so people can be hired explicitly for these roles, based on the right set of skills.

&gt; How many similarly vague “fundamentals” we have floating around us? Plenty: RESTful<p>Hell yeah, I have hardly ever seen a correct REST API in the wild. People mostly consider any non-SOAP HTTP API RESTful.

I once failed a job interview because the Fortran complier they used handled errors differently than the one I was used to, so they assumed I didn&#x27;t know what I was talking about.

it’s true that database are lying about ACID and you only get true acid if you change database isolation level from default to “serializable” but on most database (that don’t use mvcc) you would get horrible performance.<p>I still think any programmer using any database should know what “data consistency” you sacrificed for using “Read commited” instead of “serialisable” and how hacker can use it to steal million of dollar of your e-commerce company

If you know more about the fundamentals than competing job applicants then you increase your chance of getting the job.

All you need to know is the `if` statement. That&#x27;s all.

ACID is the kind of fundamental which can make the difference between easily constructing a reliable system and constructing an unreliable system with great difficulty. It&#x27;s a mistake to class it with the MVC pattern (now diluted past all recognition) and SOLID just because they&#x27;re all acronyms and your source of information about ACID was a shitty Wild Hog book by someone who wasn&#x27;t clear about what it was either.<p>You can build bridges that don&#x27;t fall down without knowing the difference between stress and strain; you can build an audio amplifier without knowing the difference between voltage and current; and you can build a database-backed application without knowing what ACID means. But you shouldn&#x27;t, except maybe as a learning exercise, because it&#x27;s an enormous amount of effort to produce mediocre results. Understanding ACID allows you to treat a database as &quot;a black box with an API&quot; with enormously better results.<p>I have no patience for the kind of glorification of ignorance in this post. Perhaps it&#x27;s true that &quot;the majority of programmers&quot; think &quot;something being RESTful means that you can feed it chunks of JSON over HTTP.&quot; The majority of audiophiles might think that oxygen-free copper will improve their sound quality, the majority of computer users might think that Google built the Internet, and the majority of people don&#x27;t speak English. That has no bearing on the knowledge needed to actually build a working hi-fi system, debug an internet connection problem, or successfully converse in English, and neither does popular ignorance about REST (or ACID) have any bearing on the knowledge needed to successfully design a distributed system that works reliably in the face of constant partial failures.<p>(Ivanhoe&#x27;s post at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29065438" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29065438</a> is an excellent explanation of what can happen when you lack the understanding of these fundamentals but mistakenly think you can use the database as a black box anyway: &quot;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&#x27;s business as well as my own, as it was our core client.&quot;)<p>If over 40 years you spend 83000 hours working, and you spend 10% of them on programming, that&#x27;s 8300 hours. (If your job title is &quot;software engineer&quot; you probably spend more like 50% of them on programming, but maybe you&#x27;re a web designer, a database administrator, a sysadmin, a mechanical engineer, or a biologist, so programming is a relatively minor part of your work.) The optimal fraction of that time spent on getting to know the fundamentals --- real fundamentals like ACID, not fake fundamentals like SOLID, though this presumes that you have someone to guide you who knows the difference --- is surely not 100%, because then you&#x27;ll never get any work done. But it&#x27;s not 0% either; you won&#x27;t get much done that way either. It&#x27;s probably in the range of 20% to 60%, which would be 1700-5000 hours. Learning in your bones what ACID is might take you 5 hours spread over a month or two, so it only takes up 0.3%-0.1% of that time.