4 ms·

This reminded me of a feature request I dealt with at an employer, while working on backoffice software for a support team. The software loaded a list of all cu

by devmor 1y ago

This reminded me of a feature request I dealt with at an employer, while working on backoffice software for a support team. The software loaded a list of all current customers on the main index page - this was fine in the early days, but as the company grew, it ended up taking nearly a whole minute before the page was responsive. This sucked. So I was tasked with fixing the issue. Instead of loading the whole list, I established a paginated endpoint and a search endpoint. The page now loaded in less than a second, and searches of customer data loaded in a couple seconds. The users hated it. Their previous way of handling the work was to just keep the index of all customers open in a browser tab all day, Ctrl+F the page for an instant result and open the link to the customer details in a new tab as needed. My upgrades made the index page load faster, but effectively made the users wait seconds every single time for a response that used to be instant at the cost of a one time per day long wait. There's a few different lessons to take from this about intent and design, user feedback, etc. but the one that really applies here is that sometimes it's just more friendly to let the user have all the data they need and allow them to interact with it "offline".

sfn42 1y ago
There's no reason you can't have the cake and eat it too. If google can index the entire web and have search results and AI results for you in an instant, then you can give users instant customer search for a mid sized corp. A search bar that actually worked fast would have done the same as their Ctrl f workflow. Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.
- thunderfork 1y ago
  [dead]
- deleted 1y ago
  [deleted]
- devmor 1y ago
  I would not consider Google search, nor its AI overview an example of a good system. It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.
  - sfn42 1y ago
    I didn't say it was good, I said it was fast. Those two things are often correlated though, the app described above certainly doesn't fit my definition of good. Computers can do unfathomable amounts of computation in the blink of an eye. If your app takes seconds or longer to do stuff it's probably because it's ass. Nearly all common operations should be measured in nano or milliseconds. If they're slow it's probably the dev's fault.
    - devmor 1y ago
      As your career goes on, you will likely eventually work on large production systems that are not idealized greenfield deployments - at this time, you will have to come to terms with the constraints of Network and I/O bounds, and your dreams of nano and milliseconds will be shattered. In particular, I welcome you to experience the lovely word of corporate VPNs, whose maintainers and developers seem to have latency expectations that have not changed in 30 years.
      - sfn42 1y ago
        I'm currently working on one of those wonderful greenfield projects where the monkeys who put it together made these mistakes I describe and everything is slow. Website isn't even in production yet and everything takes 5+ seconds to load for no reason. Because they just store the data the way they got it which is shit, instead of shaping it into something sensible that allows efficient queries. And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do. I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing. Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.

by devmor 1y ago

sfn42 1y ago

There's no reason you can't have the cake and eat it too. If google can index the entire web and have search results and AI results for you in an instant, then you can give users instant customer search for a mid sized corp. A search bar that actually worked fast would have done the same as their Ctrl f workflow. Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.

thunderfork 1y ago
[dead]
deleted 1y ago
[deleted]
devmor 1y ago
I would not consider Google search, nor its AI overview an example of a good system. It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.
- sfn42 1y ago
  I didn't say it was good, I said it was fast. Those two things are often correlated though, the app described above certainly doesn't fit my definition of good. Computers can do unfathomable amounts of computation in the blink of an eye. If your app takes seconds or longer to do stuff it's probably because it's ass. Nearly all common operations should be measured in nano or milliseconds. If they're slow it's probably the dev's fault.
  - devmor 1y ago
    As your career goes on, you will likely eventually work on large production systems that are not idealized greenfield deployments - at this time, you will have to come to terms with the constraints of Network and I/O bounds, and your dreams of nano and milliseconds will be shattered. In particular, I welcome you to experience the lovely word of corporate VPNs, whose maintainers and developers seem to have latency expectations that have not changed in 30 years.
    - sfn42 1y ago
      I'm currently working on one of those wonderful greenfield projects where the monkeys who put it together made these mistakes I describe and everything is slow. Website isn't even in production yet and everything takes 5+ seconds to load for no reason. Because they just store the data the way they got it which is shit, instead of shaping it into something sensible that allows efficient queries. And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do. I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing. Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.