5 ms·

> I don’t know what problem domains The addendum about network calls in a loop makes it sound like his domain uses some kind of SDK with a bad API design. Ther

> I don’t know what problem domains The addendum about network calls in a loop makes it sound like his domain uses some kind of SDK with a bad API design. There are some notorious examples which are known to fool new and uninitiated developers who haven't read the fine print into writing code that looks perfectly reasonable on the surface, but does dumb things under the hood. My experience with new devs is more towards obsessive concern with respect to time complexity, at least where isn't hidden behind a bad API design, fearing an algorithm with high complexity that when measured under its practical use would be just fine. It can be difficult for new (and even old) developers to grasp just how fast computers actually are.

edgyquant 3y ago
I work in multiple problem domains as I lead teams on multiple projects across orgs. My comment about network requests is because one of the most common issues I see in inexperienced engineers is writing database code locally where they add a lookup and insert on some dataset inside of a loop. Regardless of language this is unacceptably slow when a real network is involved.
- randomdata 3y ago
  Yeah, a lot of database management systems have really bad API designs, often mirroring the underlying database API directly to the user over the network without any further consideration towards the network having different constraints. Said database APIs are typically not unreasonable when the database is running in the same memory space as the application, where latency is unnoticeable, as historically was the case when a lot of these APIs were designed. But, as you know, the model breaks as soon as you find yourself in a high latency environment, like over a network. So then you get some weird bulk operators bolted onto the system to work around the latency issue, but they don't fit the mental model of the rest of the API designed around the idea of single unit operations. Save catching it in the fine print, they go unnoticed. Indeed, the naive programmer who hasn't yet been burned will not be able to fathom that another developer could design such a bad API and will put faith in the idea that the underlying system will somehow automatically mitigate the problem you describe. And in small scale testing it works fine, so there is no reason to doubt that notion. That is, until it is too late... The experienced developer has learned to stop trusting other developers and bring a heavy skepticism when using another's API. This is a blessing as it means they (usually) stop making those kinds of mistakes when they encounter a bad API, but it is curse as it means they see no reason to fix the problem. "Why don't the junior devs just know better?!" they say. And so, the cycle repeats.

edgyquant 3y ago

I work in multiple problem domains as I lead teams on multiple projects across orgs. My comment about network requests is because one of the most common issues I see in inexperienced engineers is writing database code locally where they add a lookup and insert on some dataset inside of a loop. Regardless of language this is unacceptably slow when a real network is involved.

randomdata 3y ago
Yeah, a lot of database management systems have really bad API designs, often mirroring the underlying database API directly to the user over the network without any further consideration towards the network having different constraints. Said database APIs are typically not unreasonable when the database is running in the same memory space as the application, where latency is unnoticeable, as historically was the case when a lot of these APIs were designed. But, as you know, the model breaks as soon as you find yourself in a high latency environment, like over a network. So then you get some weird bulk operators bolted onto the system to work around the latency issue, but they don't fit the mental model of the rest of the API designed around the idea of single unit operations. Save catching it in the fine print, they go unnoticed. Indeed, the naive programmer who hasn't yet been burned will not be able to fathom that another developer could design such a bad API and will put faith in the idea that the underlying system will somehow automatically mitigate the problem you describe. And in small scale testing it works fine, so there is no reason to doubt that notion. That is, until it is too late... The experienced developer has learned to stop trusting other developers and bring a heavy skepticism when using another's API. This is a blessing as it means they (usually) stop making those kinds of mistakes when they encounter a bad API, but it is curse as it means they see no reason to fix the problem. "Why don't the junior devs just know better?!" they say. And so, the cycle repeats.