Hacker News Reader

Comment by dusted | Hacker News Reader

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..

View on HN

> 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.

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.

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.

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?

In an agency setting anyways the percentage of billable time is usually a kpi

In some places, such as the one I'm working in right now, explicitly discourage working on anything but what you've been assigned. I've even been scolded from taking items from the next sprint when I was done with the current (and in no position to really help my colleagues).

In my experience, pretty close to constantly working on whatever has been prioritized from above and needing actively to push back and have exceptionally good arguments for improving things that are not in scope.

> Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments?

A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.

Almost every developer can fit a bit of discretionary work into their existing stories. You can polish up the performance when you first code it.

Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development.

Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead.

Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores.

And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?

A programmer? The gp talked about promotion as an incentive. 15 or maybe 20 years ago people didn't go into programming as a profession so much as they got paid to do what they would have done anyway. That was after the first dotcom bust, so maybe some people before that were in it for the money. But the number of times I have had to apologize to the wife because I got lost in a problem and was late getting home is large. Heck on /. they would have questioned that I actually had a wife, because programmers don't date. The motivation of the people doing the job has changed now that it pays well. But also, the culture of "if you aren't working your backlog item you aren't working" is new. The scrum kanban thing is somewhat to blame. Waterfall was terrible, but everyone on a good team knew that and just did what made sense, which is kind of what the agile manifesto was about.

Omg I’m a younger gen it sounds like, but I’m constantly getting in trouble with my wife for getting too lost in a problem. She hates, too, that I can continue to be lost in it even as I’m eating dinner or walking with her in the park or whatever. As for where that energy goes…when an employer tells me that in order to do XYZ I need to open tickets and write stories and and and, even though I agree those are the right things to do, my brain is more likely to the attack the problems where all that distracting bullshit is unnecessary.

(others) YMMV but I usually don't. It's the complexity of the problems which I need to tackle and for which I have no playbook to follow and it will mostly involve deep understanding of HW, operating systems and algorithmic design. There're also compilers and programming languages which do require a non-trivial amount of time to understand but also keeping the pace with it because they're constantly evolving. Pick any of those to study and I guarantee that you can spend your lifetime doing so without having a single second to spare. However, to provide an actual business value to your company, you obviously cannot keep running through this rabbit hole on and on but by the end of the day you have to learn how to pick the right balance. In the end, I'd say that the problem space is simply too huge and I personally haven't found myself idling in my 10+ year career other than in the moments when I became too frustrated with the problem at hand. That's also one of the reasons I am reconsidering what I want to do in next 5-10 years :)

Unless it can be made billable it is usually frowned upon.

This is the exact issue I face at my present job. Our clients have low budgets for hosting, and that means code needs to be as optimized as possible.

Sadly, the people I report to don't care enough about it. All they want is to push through the visible changes as fast as possible. And every single time these performance bugs come to bite us.

Our solution? Scale the system resources.

I'm not particularly satisfied with the work. But as an engineer I don't get to call the shots.

Eventually, this attitude develops software that takes all day to generate erroneous results and nobody really understands the code because it was all added quickly without refactoring. It's the dark side of "Do the Simplest Thing that could Possibly Work" which is probably the most misunderstood practice in XP.

At that point, every developer on the team becomes an interchangeable useless warm body and the promotion goes to the "rock star" from outside who comes in and rewrites it or surgically fixes the top performance issues.

Plenty of people would have made the mistake, few would have left it there for years after performance was absymal.

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.

> 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.

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.

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/ or 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.

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

I cannot comment on the comparison with Bundesliga footballers, because I have no experience in working a physical job. I am a knowledge worker.

So who is supposed to be benefiting from the 'exploitation'?

Management gets fat bonuses for reaching profitability targets, investors are happy.

I mentioned that investors don't seem to be getting any special benefit, if you look at the stock (including re-invested dividends).

Public investors may not be getting any benefit, because the private investors have already IPOd at a ridiculous stock price. Private investors usually have non-trading shares. The way the scheme works is that if they find the stock price to be right, they convert their non-trading shares into trading shares and profit more. This way the stock price doesn't increase much. They basically dilute the amount of public shares for profit.

They don't give any thought to public investors such as you and me.

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.

> 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

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.

There's a big difference between latency vs throughput.

We had lots of 'free' improvements in throughput. But latency still requires careful attention.

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.

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.

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.

If you’ve updated your phone’s OS since then, you now have additional services running in the background. Things like on-device face detection for photos, “suggest apps” functionality, and others.

Perhaps, but I still get zero benefit from any of those.

Indeed. Personally I think that this kind of “helpful service bloat” is part of how companies are getting away with slowing phones down over time.

Apple for example barely mentions the fact that these services are running, and certainly does not give you any way to turn them off.

My phone is about 6 years old. It's not noticeably slower than when I got it and it's running a lot more in the background than it used to.

My original SE is definitely slower.

But the weather app now has lightning animations when there's a thunderstorm! Innovation!

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.

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!”

"ship as much as possible as fast as possible" can lead to that kind of result (i've seen it over and over...)

They were very strict on manual reviews but when numbers became more important they let their guidelines slide.

> 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.

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

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.

An alternate view is that the state of program optimization is terrible.

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 , which discusses among others whether a two-way communication between compiler and developer may help.

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.

For sure. But not just "development by committee" also "development by hundreds of unrelated committees". By which of course I mean the full stack of dependencies that everything relies upon now, along with all the glue code in between that has to repeatedly transform data as it gets passed around through the system.

I've often seen some dependency module be the bottleneck, and an in-house replacement that does just what we need can perform an order of magnitude or two better than a generic 'all things for all people' module.

Also there are things that work well for dozens or hundreds of data pieces but become abysmal when you eventually scale to hundreds of thousands. But no one else has that use case, so it works fine for them. And for those that do, by then the frog is boiled and they're used to it being slow.

yea, we went from being burned by trying to optimize before we knew the problem, to being burned by not optimizing because we knew the problem but didn't optimize.

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.

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.

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.

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...

> 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.

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.

Especially when we as modern users run multiple applications, each of them deciding optimization is not worth bothering with.

That's not what I said, at all. Optimisation where it matters is important.

I’m not sure if you meant to reply to me. I was commenting on what dusted said

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

Reply on news.ycombinator.com