5 ms·

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 crit

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.
  - yowlingcat 7y ago
    I get the sense that you and other commentators are putting a certain binary in place, and I'm not sure it's in good faith. Nobody ever said that you have to pick one particular place to be an expert in, and if you're not an expert there, you're not a good engineer. That's an absurd argument, but it's also not what is being said. The truth is, you need to be good enough at all of the high priority parts of technical competency. Security, monitoring, performance -- sure, all of those are also extremely important. They're all places where unforced errors can be introduced that can and do hurt the business -- sometimes catastrophically or fatally. With that said, to not recognize the evergreen utility of domain design skills is ignorant. You will never get the luxury to worry about security, monitoring, or performance if you don't build the state machine that makes the right outputs out of the right inputs because you will either never sell it to a customer, or lose that customer when they choose a competing solution which actually does what it's supposed to do. It's not true that everything is equally important. I think that's a myopic way to look at software development without considering the business impact of key crucial areas where software design and maintenance intersect with stakeholders.
  - taffer 7y ago
    > Your business won't succeed if you're hacked daily. Which can be the consequence of setting the wrong isolation level: http://www.bailis.org/papers/acidrain-sigmod2017.pdf http://www.bailis.org/papers/acidrain-sigmod2017.pdf
- wehrkeoruw 7y ago
  We're having this conversation as if everyone making SQL queries is one fat finger away from irrevocable data loss. I know very little about SQL but have managed to build literally dozens of systems on top of Postgres without ever causing a data loss event as a result of my poor SQL skills...
  - arbie 7y ago
    I think we are seeing the difference between software development and software engineering laid bare. The distinction is similar to a property developer and a civil engineer. Both create buildings, but one does it at scale by offloading functions to known entities and prepackaged solutions, while the other understands one domain in depth. Both are needed in any team or organization, because not every solution needs to be "engineered" (a Dockerized Redis instance without SSL or auth behind a corporate firewall may survive untouched for a decade), but sometimes you have to engineer something that withstands gale-force winds at 1000 ft height.
- scarface74 7y ago
  Even if you are using an RDMS it doesn’t help to protect you against many business rule violations. Your data may be relationally correct, but that’s about it.

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.
- yowlingcat 7y ago
  I get the sense that you and other commentators are putting a certain binary in place, and I'm not sure it's in good faith. Nobody ever said that you have to pick one particular place to be an expert in, and if you're not an expert there, you're not a good engineer. That's an absurd argument, but it's also not what is being said. The truth is, you need to be good enough at all of the high priority parts of technical competency. Security, monitoring, performance -- sure, all of those are also extremely important. They're all places where unforced errors can be introduced that can and do hurt the business -- sometimes catastrophically or fatally. With that said, to not recognize the evergreen utility of domain design skills is ignorant. You will never get the luxury to worry about security, monitoring, or performance if you don't build the state machine that makes the right outputs out of the right inputs because you will either never sell it to a customer, or lose that customer when they choose a competing solution which actually does what it's supposed to do. It's not true that everything is equally important. I think that's a myopic way to look at software development without considering the business impact of key crucial areas where software design and maintenance intersect with stakeholders.
- taffer 7y ago
  > Your business won't succeed if you're hacked daily. Which can be the consequence of setting the wrong isolation level: http://www.bailis.org/papers/acidrain-sigmod2017.pdf http://www.bailis.org/papers/acidrain-sigmod2017.pdf
wehrkeoruw 7y ago
We're having this conversation as if everyone making SQL queries is one fat finger away from irrevocable data loss. I know very little about SQL but have managed to build literally dozens of systems on top of Postgres without ever causing a data loss event as a result of my poor SQL skills...
- arbie 7y ago
  I think we are seeing the difference between software development and software engineering laid bare. The distinction is similar to a property developer and a civil engineer. Both create buildings, but one does it at scale by offloading functions to known entities and prepackaged solutions, while the other understands one domain in depth. Both are needed in any team or organization, because not every solution needs to be "engineered" (a Dockerized Redis instance without SSL or auth behind a corporate firewall may survive untouched for a decade), but sometimes you have to engineer something that withstands gale-force winds at 1000 ft height.
scarface74 7y ago
Even if you are using an RDMS it doesn’t help to protect you against many business rule violations. Your data may be relationally correct, but that’s about it.