10 ms·

This kind of idiocracy reminds me of the GTA json thing.. It's kind of hard to attribute these things to ignorance, but there's been a notable shift in percepti

by dusted 4y ago

This kind of idiocracy reminds me of the GTA json thing.. It's kind of hard to attribute these things to ignorance, but there's been a notable shift in perception among developers.. It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list".. Even IF you had to do such a terrible and expensive operation, you'd at least have the good sense to save your result so that you can do it more efficiently the next time..

terminalcommand 4y ago
Alternative opinion here, 30 years ago games/software were much simpler. I assume we did not have conglomerates like Rockstar and EA who pushed their employees beyond their limits. Game industry is notoriously known for exploiting programmers. Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier.
- eru 4y ago
  > Game industry is notoriously known for exploiting programmers. I'd be wary with these kinds of words. The thing is that people seem really, really eager to work in the video games industry. (Just like people are really eager to be artists or musicians or pet vets or teachers etc.) Approximately everyone who programs for the game industry could also land a cushy job writing boring CRUD software. I do admit that it's tempting to show compassion for people who put up with crappy working conditions and low pay in order to work in their beloved field. (Especially if that field sounds socially desirable like teaching.) But unless you severely restrict entry to the beloved industry, conditions and pay will always be lousy compared to what similar skills could get you in an unglamorous field. That's just supply and demand. > Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier. In the case of the game industry, more likely so that you could work on the next ticket during the eternal death march.
  - terminalcommand 4y ago
    Isn't it exploitation to benefit from programmers'/designers' love of gaming? Labour laws are there for a reason. I believe it is a basic human right to work reasonable hours and rest. Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious. I personally would prefer ethically coded games if such a category existed. I get no fun from playing a game from a company that I know exploits people. Maybe that is the reason why indie games are so popular.
    - eru 4y ago
      As I said, programmers can already find relatively cushy CRUD jobs. So any 'exploitation' is in some sense voluntary. Would you say that Bundesliga footballers are exploited? They physically work much harder than programmers in the game industry. > Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious. You can have a look at video game industry stock indexes. See eg https://etfdb.com/etfs/industry/gaming/ https://etfdb.com/etfs/industry/gaming/ or https://www.investopedia.com/articles/investing/010616/top-4-entertainment-etfs-2016-pej-xly.asp https://www.investopedia.com/articles/investing/010616/top-4... If there's evil exploitation and excess profit, they don't seem show up in returns to shareholders. At least no better returns than any other industry. Including those with the cushy CRUD dev jobs.
      - terminalcommand 4y ago
        Sorry, I think you are mistaking stock price and profits. ETFS' performance is based on stock prices. Game companies still continue to make millions in profits. Stock price is not a reflection of profits. Hiring a recent college grad and working him 12+ hours a day with no rest is IMHO exploitation. This is why we have labour laws in the first place. Employers have too much power and influence. Offer a college grad the chance to work on games and above average pay, you get him on the hook. What you are not saying to him is that you'll overwork him breaching labour laws. I gave him a job, he wanted it, if he doesn't like it, he can leave is not sufficient to make it ethical nor legal. Please read this insider story on how brutal the working conditions are: https://ea-spouse.livejournal.com/274.html https://ea-spouse.livejournal.com/274.html I cannot comment on the comparison with Bundesliga footballers, because I have no experience in working a physical job. I am a knowledge worker.
- dusted 4y ago
  Certainly, I see I'm coming across as bashing the devs, that's not my intention.. It is my personal experience that cost of implementation is almost always the main restraint, it sounds rational when we put it this way.. Don't spend more on implementation than is needed.. Defining what's needed is more difficult.
- smartmic 4y ago
  > Alternative opinion here, 30 years ago games/software were much simpler. Funny coincidence, yesterday I posted a link which supports exactly your statement (even the 30 years): https://news.ycombinator.com/item?id=33018669 https://news.ycombinator.com/item?id=33018669
edanm 4y ago
Yeah, I don't buy it. I've been programming for more than 20 years, and I'm pretty sure people were making the same complaints 20 years ago that this article and you are making now. For some software, performance is important. For others, it isn't. Some developers are good, at least at making performant software, some are worse. That's always been true and will probably always be true.
- eru 4y ago
  There's a big difference between latency vs throughput. We had lots of 'free' improvements in throughput. But latency still requires careful attention.
- chaosbolt 4y ago
  It's not even a good vs bad dev issue most of the time, I can imagine lots of devs at Rockstar who hate working there and are under strict deadlines from managers so they just make it work while they leetcode and apply to faang for better salaries where they'll "finally" optimize things, etc.
- loup-vaillant 4y ago
  Still, software is slowing down. Anecdotal example: my phone. It used to run fine at the beginning then now a few years later everything is slow: Google maps, YouTube, Signal, the pin-code screen… I barely have installed any apps, the only thing that changed is the number of messages I have and the updates. Perhaps we could justify it with new features at least? Perhaps my phone is slower now because the things in there are so much more useful now? Well, no. I got maybe a couple cosmetic changes, but functionality is exactly the same. My phone got slower for no benefit.
  - dockd 4y ago
    But the weather app now has lightning animations when there's a thunderstorm! Innovation!
  - kaba0 4y ago
    Well, it may be just planned obsolescence, or a system-wide bug. Chances are it would be mostly as snappy as new, if you were to reinstall it and start anew, for example. In my opinion the problematic layer is usually the highest one, the kernel/low-level OS layer doesn’t have too many performance problems.
Manuel_D 4y ago
> 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list".. I think plenty of people would have made the error of filtering after applying an expensive operation than before. This seems like a classic rookie mistake, not an indication of some paradigm shift in thinking. What was impressive was that no one at Rockstar thought of improving the loading performance for so long that a use decided to reverse-engineer it.
- yellow_lead 4y ago
  I think some of these issues should be looked through a lens of incentives though as well. At my previous job, management didn't care much about performance improvements or bug fixes, they care more about delivering projects or big features. Fixing stuff like this wouldn't help you get promoted.
  - dusted 4y ago
    Absolutely, from a local perspective, decisions (or lack thereof) in regards to performance and efficiency make perfect sense, they simply shift the cost to the customer.. Pay less for development at the cost of performance which the customer will pay for with more computing capacity, electricity and time. It scales terribly though, something that may cost an additional $20000 in development cost, may cost each customer a few tens of dollars over the lifetime of the product (not including putting a price on frustration and quality of life).. But if they have a few million customers using that feature, it's terrible for society and the greater economy/ecology. Not only due to electricity, but also the high rate of replacing perfectly working computing equipment for higher-performing, only to spend any additional capacity running increasingly crappy and demanding software.
  - vultour 4y ago
    Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant agile crunch to smash as many story points as possible into the current sprint?
nikanj 4y ago
We went from ”premature optimization is evil” to ”optimization is evil”
- zweifuss 4y ago
  Having a list of all audio recordings always shown on the right pane is kinda an optimization (VoiceRecorder.exe). The usefulness is limited, because VoiceRecorder can't edit them, only play back and set markings.
- shrimpx 4y ago
  An alternate view is that the state of program optimization is terrible.
  - kaba0 4y ago
    Well, optimizations need good abstractions to work with. The reason why a SQL query can run much faster than a naive for loop would is precisely due to SQL being very removed from lower-level details. So in extension, optimization is terrible because we might be using the wrong abstraction level? E.g. it is hard to optimize a larger JS program, because if the developer specified some sort of detail it might throw out an entire class of possible optimizations. There is actually an interesting presentation on the topic here: https://news.ycombinator.com/item?id=9396950 https://news.ycombinator.com/item?id=9396950 , which discusses among others whether a two-way communication between compiler and developer may help.
- Cthulhu_ 4y ago
  I don't think either is true. I think it's a case of "development by committee" - many different people work on a codebase, but nobody is critical enough of the whole product. I can imagine the audio recorder is a low priority minor side project that gets handed from one guy (or team) to the next every couple of years, with the emphasis on "don't spend too much time on it". The other issue is that performance is taken for granted; if something is slow, it's not immediately obvious.
  - 4y ago
seydor 4y ago
too many developers means they switched from trying to emulate the elites to trying to follow the trend of the day, because otherwise you get ostracized by the crowd
maccard 4y ago
I disagree, software has always sucked. We can remember lots of the good software, and back how things used to be but the reality is this is nostalgia speaking. A perfect example is windows 95 - wiggling the mouse causes a huge speedup in long running applications [0]. > used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. That "tricking" came with lots of issues. Massive security holes, significant app stability issues, and hugely increased developer time to implement things. I can get a hardware accelerated Sha1 hash of a buffer in one line of c++ today, and I know it will be correct. People who do that work still exist. Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, but people like Casey Muratori, Bruce Dawson, still exist and still write code. [0] https://retrocomputing.stackexchange.com/questions/11533/why-did-moving-the-mouse-cursor-cause-windows-95-to-run-more-quickly https://retrocomputing.stackexchange.com/questions/11533/why...
- dusted 4y ago
  > Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, And this attitude is what gives us such gems as the one mentioned in the OP article.
  - maccard 4y ago
    No, it's not. Not at all. I care about performance in my architecture, design, and code. However I _don't_ care about eeking out every %ge in every scenario. The difference is caring where it matters. Bugs and mistakes happen. The measure of someone who cares and someone who is improving is how they handle it when these issues happen.
  - joshspankit 4y ago
    Especially when we as modern users run multiple applications, each of them deciding optimization is not worth bothering with.
slowmotiony 4y ago
Funny enough, if you read the guidelines for Metro apps (or Modern apps, or UWP apps, or whatever the hell they are called now), Microsoft specifically says that you should offload all expensive operations to an async thread and keep the UI thread free so the interface can be quick and responsive. When I was making my first apps in university, they would routinely reject them from their app store saying the UI is not responsive enough. You'd think they actually care about efficiency and responsiveness. But then they hardcode a whole Documents directory scan right in the UI thread in their own damn voice recorder app. Unbelievable.
- sebazzz 4y ago
  They were very strict on manual reviews but when numbers became more important they let their guidelines slide.
- joshspankit 4y ago
  I wonder if they only ever tested the UI when there were less than 3 files on that folder. “Looks fast to me! Ship it.” “Looks fast to me too! Approve it!”
  - andrekandre 4y ago
    "ship as much as possible as fast as possible" can lead to that kind of result (i've seen it over and over...)
dan-robertson 4y ago
30 years ago, much (UNIX) system software was built out of calls to system(), ie it would have shell commands do most of the steps. Partly this is because it is hard to do everything in C and partly it is just laziness. This is partly the reason for terrible security (the IFS environment variable could be changed to change the meaning of the system() calls and trivially make a suid program do bad things). I think you’re giving programmers of the past too much credit.
- salawat 4y ago
  I think you're not giving them enough. They managed to have a glaring security hole to be exploited, but no one bothered to. It took the bunch of degenerates we have around today with no respect for the sanctity of someone else's machine for this type of practice to even become a problem. You'll be amazed how many seemingly intractable technical issues aren't due to having been solved at higher layers of abstraction. Nowadays with things like clear cut ownership of post first sale ownership breaking down, we're actually getting bitten by having to try to technically solve problems, previously made tractable by the social consensus between professionals. As a consequence, here we are with a now crappy, pathological Notepad.
  - dan-robertson 4y ago
    We must be talking about a different 1990s. It’s true that before then it was easier to get away with bad security due to few computers being networked, and it took a while for eg buffer overflows to be exploited (smashing the stack for fun and profit was November ’96). But in the first half of the decade or so there were lots of vulnerabilities found in sendmail and suchlike.
scruple 4y ago
> It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. We didn't used to have product teams as large as engineering teams. You can still engineer software the way you want, you're just beholden to some product persons idea about deadlines now. If you can turn your little unit of work around quickly no one will bat an eye (of course, we all know that's not realistic most of the time). If you dare trying to take longer than their perception of how long it ought to take then you better be prepared to discuss the "value add" of your performance minded solution as nauseum.

by dusted 4y ago

terminalcommand 4y ago

Alternative opinion here, 30 years ago games/software were much simpler. I assume we did not have conglomerates like Rockstar and EA who pushed their employees beyond their limits. Game industry is notoriously known for exploiting programmers. Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier.

eru 4y ago
> Game industry is notoriously known for exploiting programmers. I'd be wary with these kinds of words. The thing is that people seem really, really eager to work in the video games industry. (Just like people are really eager to be artists or musicians or pet vets or teachers etc.) Approximately everyone who programs for the game industry could also land a cushy job writing boring CRUD software. I do admit that it's tempting to show compassion for people who put up with crappy working conditions and low pay in order to work in their beloved field. (Especially if that field sounds socially desirable like teaching.) But unless you severely restrict entry to the beloved industry, conditions and pay will always be lousy compared to what similar skills could get you in an unglamorous field. That's just supply and demand. > Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier. In the case of the game industry, more likely so that you could work on the next ticket during the eternal death march.
- terminalcommand 4y ago
  Isn't it exploitation to benefit from programmers'/designers' love of gaming? Labour laws are there for a reason. I believe it is a basic human right to work reasonable hours and rest. Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious. I personally would prefer ethically coded games if such a category existed. I get no fun from playing a game from a company that I know exploits people. Maybe that is the reason why indie games are so popular.
  - eru 4y ago
    As I said, programmers can already find relatively cushy CRUD jobs. So any 'exploitation' is in some sense voluntary. Would you say that Bundesliga footballers are exploited? They physically work much harder than programmers in the game industry. > Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious. You can have a look at video game industry stock indexes. See eg https://etfdb.com/etfs/industry/gaming/ https://etfdb.com/etfs/industry/gaming/ or https://www.investopedia.com/articles/investing/010616/top-4-entertainment-etfs-2016-pej-xly.asp https://www.investopedia.com/articles/investing/010616/top-4... If there's evil exploitation and excess profit, they don't seem show up in returns to shareholders. At least no better returns than any other industry. Including those with the cushy CRUD dev jobs.
    - terminalcommand 4y ago
      Sorry, I think you are mistaking stock price and profits. ETFS' performance is based on stock prices. Game companies still continue to make millions in profits. Stock price is not a reflection of profits. Hiring a recent college grad and working him 12+ hours a day with no rest is IMHO exploitation. This is why we have labour laws in the first place. Employers have too much power and influence. Offer a college grad the chance to work on games and above average pay, you get him on the hook. What you are not saying to him is that you'll overwork him breaching labour laws. I gave him a job, he wanted it, if he doesn't like it, he can leave is not sufficient to make it ethical nor legal. Please read this insider story on how brutal the working conditions are: https://ea-spouse.livejournal.com/274.html https://ea-spouse.livejournal.com/274.html I cannot comment on the comparison with Bundesliga footballers, because I have no experience in working a physical job. I am a knowledge worker.
dusted 4y ago
Certainly, I see I'm coming across as bashing the devs, that's not my intention.. It is my personal experience that cost of implementation is almost always the main restraint, it sounds rational when we put it this way.. Don't spend more on implementation than is needed.. Defining what's needed is more difficult.
smartmic 4y ago
> Alternative opinion here, 30 years ago games/software were much simpler. Funny coincidence, yesterday I posted a link which supports exactly your statement (even the 30 years): https://news.ycombinator.com/item?id=33018669 https://news.ycombinator.com/item?id=33018669

edanm 4y ago

Yeah, I don't buy it. I've been programming for more than 20 years, and I'm pretty sure people were making the same complaints 20 years ago that this article and you are making now. For some software, performance is important. For others, it isn't. Some developers are good, at least at making performant software, some are worse. That's always been true and will probably always be true.

eru 4y ago
There's a big difference between latency vs throughput. We had lots of 'free' improvements in throughput. But latency still requires careful attention.
chaosbolt 4y ago
It's not even a good vs bad dev issue most of the time, I can imagine lots of devs at Rockstar who hate working there and are under strict deadlines from managers so they just make it work while they leetcode and apply to faang for better salaries where they'll "finally" optimize things, etc.
loup-vaillant 4y ago
Still, software is slowing down. Anecdotal example: my phone. It used to run fine at the beginning then now a few years later everything is slow: Google maps, YouTube, Signal, the pin-code screen… I barely have installed any apps, the only thing that changed is the number of messages I have and the updates. Perhaps we could justify it with new features at least? Perhaps my phone is slower now because the things in there are so much more useful now? Well, no. I got maybe a couple cosmetic changes, but functionality is exactly the same. My phone got slower for no benefit.
- dockd 4y ago
  But the weather app now has lightning animations when there's a thunderstorm! Innovation!
- kaba0 4y ago
  Well, it may be just planned obsolescence, or a system-wide bug. Chances are it would be mostly as snappy as new, if you were to reinstall it and start anew, for example. In my opinion the problematic layer is usually the highest one, the kernel/low-level OS layer doesn’t have too many performance problems.

Manuel_D 4y ago

> 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list".. I think plenty of people would have made the error of filtering after applying an expensive operation than before. This seems like a classic rookie mistake, not an indication of some paradigm shift in thinking. What was impressive was that no one at Rockstar thought of improving the loading performance for so long that a use decided to reverse-engineer it.

yellow_lead 4y ago
I think some of these issues should be looked through a lens of incentives though as well. At my previous job, management didn't care much about performance improvements or bug fixes, they care more about delivering projects or big features. Fixing stuff like this wouldn't help you get promoted.
- dusted 4y ago
  Absolutely, from a local perspective, decisions (or lack thereof) in regards to performance and efficiency make perfect sense, they simply shift the cost to the customer.. Pay less for development at the cost of performance which the customer will pay for with more computing capacity, electricity and time. It scales terribly though, something that may cost an additional $20000 in development cost, may cost each customer a few tens of dollars over the lifetime of the product (not including putting a price on frustration and quality of life).. But if they have a few million customers using that feature, it's terrible for society and the greater economy/ecology. Not only due to electricity, but also the high rate of replacing perfectly working computing equipment for higher-performing, only to spend any additional capacity running increasingly crappy and demanding software.
- vultour 4y ago
  Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant agile crunch to smash as many story points as possible into the current sprint?

nikanj 4y ago

We went from ”premature optimization is evil” to ”optimization is evil”

zweifuss 4y ago
Having a list of all audio recordings always shown on the right pane is kinda an optimization (VoiceRecorder.exe). The usefulness is limited, because VoiceRecorder can't edit them, only play back and set markings.
shrimpx 4y ago
An alternate view is that the state of program optimization is terrible.
- kaba0 4y ago
  Well, optimizations need good abstractions to work with. The reason why a SQL query can run much faster than a naive for loop would is precisely due to SQL being very removed from lower-level details. So in extension, optimization is terrible because we might be using the wrong abstraction level? E.g. it is hard to optimize a larger JS program, because if the developer specified some sort of detail it might throw out an entire class of possible optimizations. There is actually an interesting presentation on the topic here: https://news.ycombinator.com/item?id=9396950 https://news.ycombinator.com/item?id=9396950 , which discusses among others whether a two-way communication between compiler and developer may help.
Cthulhu_ 4y ago
I don't think either is true. I think it's a case of "development by committee" - many different people work on a codebase, but nobody is critical enough of the whole product. I can imagine the audio recorder is a low priority minor side project that gets handed from one guy (or team) to the next every couple of years, with the emphasis on "don't spend too much time on it". The other issue is that performance is taken for granted; if something is slow, it's not immediately obvious.
- 4y ago

seydor 4y ago

too many developers means they switched from trying to emulate the elites to trying to follow the trend of the day, because otherwise you get ostracized by the crowd

maccard 4y ago

I disagree, software has always sucked. We can remember lots of the good software, and back how things used to be but the reality is this is nostalgia speaking. A perfect example is windows 95 - wiggling the mouse causes a huge speedup in long running applications [0]. > used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. That "tricking" came with lots of issues. Massive security holes, significant app stability issues, and hugely increased developer time to implement things. I can get a hardware accelerated Sha1 hash of a buffer in one line of c++ today, and I know it will be correct. People who do that work still exist. Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, but people like Casey Muratori, Bruce Dawson, still exist and still write code. [0] https://retrocomputing.stackexchange.com/questions/11533/why-did-moving-the-mouse-cursor-cause-windows-95-to-run-more-quickly https://retrocomputing.stackexchange.com/questions/11533/why...

dusted 4y ago
> Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, And this attitude is what gives us such gems as the one mentioned in the OP article.
- maccard 4y ago
  No, it's not. Not at all. I care about performance in my architecture, design, and code. However I _don't_ care about eeking out every %ge in every scenario. The difference is caring where it matters. Bugs and mistakes happen. The measure of someone who cares and someone who is improving is how they handle it when these issues happen.
- joshspankit 4y ago
  Especially when we as modern users run multiple applications, each of them deciding optimization is not worth bothering with.

slowmotiony 4y ago

Funny enough, if you read the guidelines for Metro apps (or Modern apps, or UWP apps, or whatever the hell they are called now), Microsoft specifically says that you should offload all expensive operations to an async thread and keep the UI thread free so the interface can be quick and responsive. When I was making my first apps in university, they would routinely reject them from their app store saying the UI is not responsive enough. You'd think they actually care about efficiency and responsiveness. But then they hardcode a whole Documents directory scan right in the UI thread in their own damn voice recorder app. Unbelievable.

sebazzz 4y ago
They were very strict on manual reviews but when numbers became more important they let their guidelines slide.
joshspankit 4y ago
I wonder if they only ever tested the UI when there were less than 3 files on that folder. “Looks fast to me! Ship it.” “Looks fast to me too! Approve it!”
- andrekandre 4y ago
  "ship as much as possible as fast as possible" can lead to that kind of result (i've seen it over and over...)

dan-robertson 4y ago

30 years ago, much (UNIX) system software was built out of calls to system(), ie it would have shell commands do most of the steps. Partly this is because it is hard to do everything in C and partly it is just laziness. This is partly the reason for terrible security (the IFS environment variable could be changed to change the meaning of the system() calls and trivially make a suid program do bad things). I think you’re giving programmers of the past too much credit.

salawat 4y ago
I think you're not giving them enough. They managed to have a glaring security hole to be exploited, but no one bothered to. It took the bunch of degenerates we have around today with no respect for the sanctity of someone else's machine for this type of practice to even become a problem. You'll be amazed how many seemingly intractable technical issues aren't due to having been solved at higher layers of abstraction. Nowadays with things like clear cut ownership of post first sale ownership breaking down, we're actually getting bitten by having to try to technically solve problems, previously made tractable by the social consensus between professionals. As a consequence, here we are with a now crappy, pathological Notepad.
- dan-robertson 4y ago
  We must be talking about a different 1990s. It’s true that before then it was easier to get away with bad security due to few computers being networked, and it took a while for eg buffer overflows to be exploited (smashing the stack for fun and profit was November ’96). But in the first half of the decade or so there were lots of vulnerabilities found in sendmail and suchlike.

scruple 4y ago

> It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. We didn't used to have product teams as large as engineering teams. You can still engineer software the way you want, you're just beholden to some product persons idea about deadlines now. If you can turn your little unit of work around quickly no one will bat an eye (of course, we all know that's not realistic most of the time). If you dare trying to take longer than their perception of how long it ought to take then you better be prepared to discuss the "value add" of your performance minded solution as nauseum.