4 ms·

What would you say is the special thing about this particular bit of knowledge that made you point it out? To be perfectly honest, it seems quite arbitrary to m

What would you say is the special thing about this particular bit of knowledge that made you point it out? To be perfectly honest, it seems quite arbitrary to me. I could say I'm surprised to see how many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces. Someone else would complain about people's inability to do even the most basic Linux administration tasks. But at the end of the day any single bit of knowledge doesn't say much about your general ability to be a developer. The term "web development" covers an extremely wide array of topics. Luckily, there are many wonderful pieces of software out there that abstract things away and allow you to produce a finished product even if you aren't an expert in everything involved.

yowlingcat 7y ago
It's not arbitrary because screwing up your data integrity is far and away one of the most painful and business critical mistakes you can make as an engineer. Your product isn't finished if it looks like it works, but is either storing data improperly at rest or doing the wrong thing with it.
- jackcodes 7y ago
  I think the point to be made was that if you screw up your browser rending to the point of it being unusable on old devices, that could be just as business critical as the data integrity issue. Making either of those your line in the sand for what a developer should and shouldn’t know is arbitrary. I don’t know a ‘Scala’ full-stack developer that could do advanced optimisation on React render times, or a ‘React’ developer that knows transaction isolation. Not knowing either of these does not make you an unworthy developer and unless you have a specific need for these skills it probably does more harm than good expecting everyone to know them.
  - yowlingcat 7y ago
    The difference is that if you screw up your browser rendering, you're not messing up your data integrity at rest and creating compound technical and potential business debt. If anything in the critical path from pricing to payments that talks to your data store makes a mistake, you can risk anything from not recording your transactions properly to charging the wrong amount or not enough at all. It's very expensive to acquire customers. It gets even more expensive when you have dirty data from incomplete domain modeling.
    - littlecranky67 7y ago
      Again, you just pick data as the "one" core business critical technology. I guess you are an SQL export? There are dozens of critical points of failure. Losing your HA gateway during an expensive ad campaign, designing your network/data center wrong such that your SQL cluster goes down etc. etc. Even JavaScript that hides the "checkout" feature. I didn't even go into security (think your domain gets hijacked, or XSS injection on your site etc.).
      - yowlingcat 7y ago
        I never said there was only "one" core part of business critical technical competency. What I'd say is that there are several of them in high priority that have an out-sized effect on long term project success. One of them (security) probably has a similarly outsize effect, but everything else you're describing is operations. It doesn't have an effect on how you design your software, and whether it exhibits correct behavior. At the most basic conceptual level, the business of software rests on reading inputs correctly, processing them, and writing the right outputs with strong guarantees. SQL is historically the most sophisticated, powerful, common and cross platform way to do that in a structured manner that is easy to reason about for a vast majority of use cases. You can layer an application on top of the foundation of an appropriate data model, but the appropriate data model is a root requirement to even get to a passable prototype. That is why gradual mastery of it yields such outsize payoffs compared to mastering other skills.
    - arcticfox 7y ago
      This argument is entirely arbitrary. What about security? Your business won't succeed if you're hacked daily. What about monitoring? If you're losing data and don't even know it, you're creating compound technical and potential business debt. What about performance? Once you have a perfect data model, no amount of trying to optimize it will improve your business further. Optimizing other parts of the application can. Basically everything is important, saying that just because someone isn't an expert in one phase that they're not as good of a developer is myopic.
      - 7y ago
- littlecranky67 7y ago
  Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.
  - yowlingcat 7y ago
    I think you're proving exactly my point. SQL is intrinsically very close to the metal of your business logic, especially when it comes to general business logic. General business logic is typically most critical and risky around the surface of payments. A JavaScript bug on your site around your shop preventing checkouts is very bad because you are indeed losing cash by the minutes. A poor domain model that doesn't properly associate active promotions to cart order lines could result in an incorrect charge amount and an irate customer.
  - ThrowawayR2 7y ago
    You have got to be kidding. Corrupting data for a sale already made is far worse than losing a sale because of an outage.
    - jackcodes 7y ago
      Not when you’re corrupting only a handful of sales, but losing all of them. It still feels arbitrary to say one is more important for developers to be aware of than the other here. As long as you have both covered to a reasonable degree within your company/team it’s a waste of time arguing who’s got the most important info in their brains.
      - joyeuse6701 7y ago
        One is more important because presumably one is harder and thus more expensive to recover from. Typically the deeper the rot in the foundation, the more expensive the repair.
        stefano 7y ago
        A data corruption might be also impossible to recover from. You could even only notice it after months of it happening, e.g. if your users spend months collecting data which is only analysed at the end of the year.
- robdachshund 7y ago
  But how does one screw it up when using Django for instance? I would learn SQL if I used it directly, but I don't have to, so... why would I?
itronitron 7y ago
>> many people don't know anything about the browser rendering pipeline if you can recommend a good source for learning the browser rendering pipeline please post it here, everyone I have asked just shrugs it off and says that no one really knows.
- davidjnelson 7y ago
  This one is quite good. I posted it to Hn 6 years or so ago but it didn’t get upvotes: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ https://www.html5rocks.com/en/tutorials/internals/howbrowser...
  - gdy 7y ago
    How much of it is relevant 8 years later?
    - debaserab2 7y ago
      Nearly all of it
- simoncarter 7y ago
  Here is are a couple: https://developers.google.com/web/fundamentals/performance/rendering https://developers.google.com/web/fundamentals/performance/r... https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction https://developers.google.com/web/fundamentals/performance/c... Would be interested to hear of more also.
- davidjnelson 7y ago
  This series is also quite good, a bit more modern: https://developers.google.com/web/updates/2018/09/inside-browser-part1 https://developers.google.com/web/updates/2018/09/inside-bro...
- greenyouse 7y ago
  I'd be interested in other resources for this too. The best I can think of is Udacity's Web Performance Optimization class[0]. It's by Ilya Grigorik, chair of the W3C Web Performance working group. Other than that there are some older docs for the Blink engine which drives Chromium. It's much more low level and hard to follow though[1][2]. The Navigation Timing spec is good for building an understanding of the major events that go into a page loading and creating HTML elements[3]. It's not the whole picture but gives the timings for navigation and DOM element events. [0] https://www.udacity.com/course/website-performance-optimization--ud884 https://www.udacity.com/course/website-performance-optimizat... [1] https://www.chromium.org/developers/the-rendering-critical-path https://www.chromium.org/developers/the-rendering-critical-p... [2] https://docs.google.com/document/d/1wYNK2q_8vQuhVSWyUHZMVPGELzI0CYJ07gTPWP1V1us/edit# https://docs.google.com/document/d/1wYNK2q_8vQuhVSWyUHZMVPGE... [3] https://www.w3.org/TR/navigation-timing/#processing-model https://www.w3.org/TR/navigation-timing/#processing-model
LaGrange 7y ago
> I could say I'm surprised to see how many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces. I mean, if you're supposed to be a senior front-end dev then that wouldn't be an unreasonable expectation. Meanwhile there's plenty of senior back-end developers out there working on SQL-backed applications who don't know SQL and refuse to learn it.
liveoneggs 7y ago
by this reasoning all knowledge is arbitrary so this comment provides no value beyond arbitrarily shitting on someone
goatinaboat 7y ago
many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces No one cares about that because the website will be redone in the hottest new framework every few months anyway. Whereas serious databases are around for decades.

yowlingcat 7y ago

It's not arbitrary because screwing up your data integrity is far and away one of the most painful and business critical mistakes you can make as an engineer. Your product isn't finished if it looks like it works, but is either storing data improperly at rest or doing the wrong thing with it.

jackcodes 7y ago
I think the point to be made was that if you screw up your browser rending to the point of it being unusable on old devices, that could be just as business critical as the data integrity issue. Making either of those your line in the sand for what a developer should and shouldn’t know is arbitrary. I don’t know a ‘Scala’ full-stack developer that could do advanced optimisation on React render times, or a ‘React’ developer that knows transaction isolation. Not knowing either of these does not make you an unworthy developer and unless you have a specific need for these skills it probably does more harm than good expecting everyone to know them.
- yowlingcat 7y ago
  The difference is that if you screw up your browser rendering, you're not messing up your data integrity at rest and creating compound technical and potential business debt. If anything in the critical path from pricing to payments that talks to your data store makes a mistake, you can risk anything from not recording your transactions properly to charging the wrong amount or not enough at all. It's very expensive to acquire customers. It gets even more expensive when you have dirty data from incomplete domain modeling.
  - littlecranky67 7y ago
    Again, you just pick data as the "one" core business critical technology. I guess you are an SQL export? There are dozens of critical points of failure. Losing your HA gateway during an expensive ad campaign, designing your network/data center wrong such that your SQL cluster goes down etc. etc. Even JavaScript that hides the "checkout" feature. I didn't even go into security (think your domain gets hijacked, or XSS injection on your site etc.).
    - yowlingcat 7y ago
      I never said there was only "one" core part of business critical technical competency. What I'd say is that there are several of them in high priority that have an out-sized effect on long term project success. One of them (security) probably has a similarly outsize effect, but everything else you're describing is operations. It doesn't have an effect on how you design your software, and whether it exhibits correct behavior. At the most basic conceptual level, the business of software rests on reading inputs correctly, processing them, and writing the right outputs with strong guarantees. SQL is historically the most sophisticated, powerful, common and cross platform way to do that in a structured manner that is easy to reason about for a vast majority of use cases. You can layer an application on top of the foundation of an appropriate data model, but the appropriate data model is a root requirement to even get to a passable prototype. That is why gradual mastery of it yields such outsize payoffs compared to mastering other skills.
  - arcticfox 7y ago
    This argument is entirely arbitrary. What about security? Your business won't succeed if you're hacked daily. What about monitoring? If you're losing data and don't even know it, you're creating compound technical and potential business debt. What about performance? Once you have a perfect data model, no amount of trying to optimize it will improve your business further. Optimizing other parts of the application can. Basically everything is important, saying that just because someone isn't an expert in one phase that they're not as good of a developer is myopic.
    - 7y ago
littlecranky67 7y ago
Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.
- yowlingcat 7y ago
  I think you're proving exactly my point. SQL is intrinsically very close to the metal of your business logic, especially when it comes to general business logic. General business logic is typically most critical and risky around the surface of payments. A JavaScript bug on your site around your shop preventing checkouts is very bad because you are indeed losing cash by the minutes. A poor domain model that doesn't properly associate active promotions to cart order lines could result in an incorrect charge amount and an irate customer.
- ThrowawayR2 7y ago
  You have got to be kidding. Corrupting data for a sale already made is far worse than losing a sale because of an outage.
  - jackcodes 7y ago
    Not when you’re corrupting only a handful of sales, but losing all of them. It still feels arbitrary to say one is more important for developers to be aware of than the other here. As long as you have both covered to a reasonable degree within your company/team it’s a waste of time arguing who’s got the most important info in their brains.
    - joyeuse6701 7y ago
      One is more important because presumably one is harder and thus more expensive to recover from. Typically the deeper the rot in the foundation, the more expensive the repair.
      - stefano 7y ago
        A data corruption might be also impossible to recover from. You could even only notice it after months of it happening, e.g. if your users spend months collecting data which is only analysed at the end of the year.
robdachshund 7y ago
But how does one screw it up when using Django for instance? I would learn SQL if I used it directly, but I don't have to, so... why would I?

itronitron 7y ago

>> many people don't know anything about the browser rendering pipeline if you can recommend a good source for learning the browser rendering pipeline please post it here, everyone I have asked just shrugs it off and says that no one really knows.

davidjnelson 7y ago
This one is quite good. I posted it to Hn 6 years or so ago but it didn’t get upvotes: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ https://www.html5rocks.com/en/tutorials/internals/howbrowser...
- gdy 7y ago
  How much of it is relevant 8 years later?
  - debaserab2 7y ago
    Nearly all of it
simoncarter 7y ago
Here is are a couple: https://developers.google.com/web/fundamentals/performance/rendering https://developers.google.com/web/fundamentals/performance/r... https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction https://developers.google.com/web/fundamentals/performance/c... Would be interested to hear of more also.
davidjnelson 7y ago
This series is also quite good, a bit more modern: https://developers.google.com/web/updates/2018/09/inside-browser-part1 https://developers.google.com/web/updates/2018/09/inside-bro...
greenyouse 7y ago
I'd be interested in other resources for this too. The best I can think of is Udacity's Web Performance Optimization class[0]. It's by Ilya Grigorik, chair of the W3C Web Performance working group. Other than that there are some older docs for the Blink engine which drives Chromium. It's much more low level and hard to follow though[1][2]. The Navigation Timing spec is good for building an understanding of the major events that go into a page loading and creating HTML elements[3]. It's not the whole picture but gives the timings for navigation and DOM element events. [0] https://www.udacity.com/course/website-performance-optimization--ud884 https://www.udacity.com/course/website-performance-optimizat... [1] https://www.chromium.org/developers/the-rendering-critical-path https://www.chromium.org/developers/the-rendering-critical-p... [2] https://docs.google.com/document/d/1wYNK2q_8vQuhVSWyUHZMVPGELzI0CYJ07gTPWP1V1us/edit# https://docs.google.com/document/d/1wYNK2q_8vQuhVSWyUHZMVPGE... [3] https://www.w3.org/TR/navigation-timing/#processing-model https://www.w3.org/TR/navigation-timing/#processing-model

LaGrange 7y ago

> I could say I'm surprised to see how many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces. I mean, if you're supposed to be a senior front-end dev then that wouldn't be an unreasonable expectation. Meanwhile there's plenty of senior back-end developers out there working on SQL-backed applications who don't know SQL and refuse to learn it.

liveoneggs 7y ago

by this reasoning all knowledge is arbitrary so this comment provides no value beyond arbitrarily shitting on someone

goatinaboat 7y ago

many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces No one cares about that because the website will be redone in the hottest new framework every few months anyway. Whereas serious databases are around for decades.