Hacker News Reader

Comment by Manuel_D | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com