Hacker News Reader

Your job is to make money for the company.

Your job isn't to build the smoothest, most optimized, experience for your customers. It's to build features customers want or need, which in turn create value for your employer. This generated value pays your paycheck. Of course if you do a bad enough job, it's counterproductive, but to the extent it's not bad enough your job is to focus on features and development and not on optimization. Once performance is bad enough, your job becomes optimization -- via instrumentation, measurement and profiling.

Every minute you spend waiting on a build or waiting for an app to launch or waiting for some long-running task to finish is a minute you're not creating value. Compounding this problem, it impacts morale if you spend your day looking at spinning beach balls while your boss won't get off your back about when you'll be done.

This is your employer's perspective, more than likely.

[edit] Another way of looking at this is to say that you and your customers are doing different jobs. You have all the extra cpu and memory overhead of developing a product — all they have to do is run it. By definition your workload is more demanding.

That and the cost of distractions waiting for a build. I used to work in a place where a build would take 3-4 minutes. In practice, it often took 15 as I went to Reddit or Hacker News or chatted with a co-worker and then had to remember what it was I was doing.

I think one needs to differentiate between building and manually testing the app. Running the build on a fast machine greatly benefits the development cycle while the tests are harmed because you don't test close to your users.

There used to be a time when you ran development/debugger on a different machine than the one running the application. Developers having fast machines for work should have absolutely nothing to do with not properly testing for user environments. That's just poor engineering, which unfortunately pervades today.

This is still the case in mobile development. A good setup is to build on a fast expensive PC and run your app on an old cheap phone.

I think that's part of the argument for this, yes–a company that doesn't provide their developers with the best tooling is hurting themselves because they're wasting their developer's time. But I'll argue that the opposite can be true as well! By using a machine that is far removed from what your customers are on, can you really test their user experience?

And, this is a personal anecdote of course, but sometimes having fast machines can paper over problems that you should really be addressing: I had a coworker once who temporarily used a fairly (~7 years) old machine to do their development work until they could get something newer to work on. During that time I noticed that they would take a while to make minor fixes after reviews. I asked them why and they told me that they would make the change and then they'd build it and it was taking dozens of minutes–it turns out that there was a creeping dependency tracking issue in the build process that nobody had bothered to address yet because it didn't seem like a huge issue on our normal machines. But fixing it certainly got his turnaround time way up, and the CI machines really liked the change too ;)

Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.

Or you should -know- what specs your users are using (this is really not hard) and optimize for that.

You can get chrome to degrade network performance etc. It's not easy to downgrade machine performance tho.

You can simulate a slower machine with a VM, or by disabling extra cores and memory on your dev machine, or by running your app off a slow external drive.

It's not as easy to do this as it could be, but it's not that hard either.

Simply run your app in a VM, that should degrade performance, customizable as well.

I'm not really buying that. You can limit ram access but even at a single core i7 you're going to have better JS performance than some i3 from 10 years ago.

Hypervisor / virtualization tech should mean you get very close to actual host OS performance. Otherwise this whole container thing wouldn't work so hot?

> Why would a developer be in charge of testing the user experience from the user perspective?

I can count on one hand the number of companies I've worked at in the last decade who had in-house QA teams. Most companies just rely on the developers to test their (our) own code. The exceptions are banks, gamedev companies and big corp products (like Windows).

Most web software I've seen - especially in the startup world - just assumes that "it works well enough on the developers' specced out mac" means it works. The most tragic version of this I saw was our app looking awful on a ‘normal’ 19” desktop monitor. The problem was our designers did all their work from 27" imacs. They never thought to design and test on smaller displays. Or the designers placing adjacent colors that look great on color graded displays but are almost indistinguishable on the trashy 6 bit TN displays that were ubiquitous in offices a few years ago.

Even in companies with dedicated QA I haven't seen many tickets of the form of "the program runs slowly on this old computer we have". Sadly the creeping performance rot is mostly invisible.

I worked at an education tech startup so we were mildly aware of our app being run on slowly performing computers. Low bandwith conditions were more of the worry tho.

Honestly, people running slow computers are probably just used to poor performance. I fully agree with you that we should do something about it but I don't see that happening unless it's a strong priority (feature X/y/z or performance? is usually the conversation).

Anecdotally: I'll never forget the first time I launched an app from an SSD and vowed I was never going back.

Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.

It doesn’t have to be either/or, it can be both. Developers absolutely should be using their own software frequently, seeing and feeling how well it performs; trying it out on a lower-spec machine is always a useful exercise.

That doesn’t mean you can’t also have dedicated QA. Developers shouldn’t have to be in charge of QA, but they should have some involvement.

> It's not easy to downgrade machine performance tho.

  yes > /dev/null &

Repeat until slow ;)

What about Cloud Environment?

Do you know that writing code efficiently can also save money for the company? If you try to write code that burns bandwidth or CPU cycles without even attempting to optimize it, it's gonna cost you an eye at the end of the year.

Software optimized for the slowest hardware possible actually does saves money, which helps also to reach the goal of doing more money, since more hardware is being supported, not only the cutting-edge one.

I've seeing now this infamous trend also on Android Phones boosting 90-120 Hz screens. If applications get optimized to run on these phones, whose CPU is also strong, obviously older phones are suffering and become sluggish.

Seriously, try to write code as your target platform is a Raspberry Pi 1 model. If works on it fast, it's going to be fast everywhere

That's true, but it really depends a lot on the kind of software you're writing. If you're Google or Facebook and make fractions of a cent per pageview despite doing an enormous amount of computation then optimizing your code and infrastructure is very important indeed. On the other hand someone like Airbnb is very likely to make tens or hundreds of dollars off a handful of pageviews, so cloud costs are much less of a concern.

Your job is to make cost effective decisions actually. And that’s a long game not a short game.

If you fail to make those consistently you end up with large infrastructure bills and unhappy customers eventually.

> Your job isn't to build the smoothest, most optimized, experience for your customers.

That is literally my job! You should have someone like that too, or else you'll end up shipping an Electron app like Discord does.

Discord just hit 100 million active monthly users, kind of proving OP's point. Using Electron enabled them to ship quickly and deliver on important features to users.

> [...] or else you'll end up shipping an Electron app like Discord does.

And get to dominate their market niche?

People got to realize while native apps are nice and all, there is absolutely zero evidence that going native vs cross-platform improves any metric a business actually cares about. Users are flocking to cross-platform apps in droves!

Vocal message board users screaming their preference for native apps are not in any way a significant share of the actual market for these applications.

> Users are flocking to cross-platform apps in droves!

I seriously doubt the use of Electron is what's driving that.

And it's also worth remembering that "cross-platform" ≠ "bundle an entire web browser in the app". Qt exists, as one of many examples of application frameworks/toolkits that are simultaneously cross-platform and native.

> I seriously doubt the use of Electron is what's driving that.

It is indirectly driving that.

Using Electron instead of other cross-platform frameworks like Qt allows one to work faster since you can apply webdev knowledge, and that directly leads to features that users actually care about being delivered faster.

Okay, and what good are those features if users are afraid to run the app lest it eat all their RAM for breakfast?

Like, if you just need to spit out a prototype to hit the ground running fast, then fine, but long-term there are pretty clear benefits to using the right tool for the job.

The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.

> Okay, and what good are those features if users are afraid to run the app lest it eat all their RAM for breakfast?

There is no evidence to believe that users are concerned about RAM usage to any level that would move them over to competing apps.

> The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.

There are orders of magnitude more web devs than devs who are even just familiar with desktop GUI toolkits. Even if you can find people who are just as productive with (for example) Qt, they'd be (way) more expensive than the average web dev.

And, again, now you have less budget to spend on things that actually gets you users.

In my first job, management purposely prohibited developers from using really powerful machines because we needed to make the software faster. The problem was it was hard to make the software faster because it was so slow to run, measure, and verify changes.

Those managers were eventually all let go and one of the first things new management did was buy us the most powerful machines they could find and institute performance regression tests that rachetted down. Each change could only keep the existing performance or make it faster. And changes that made it faster set the new watermark. Regressions required management approval.

After performance having been unimproved for a year, it was largely resolved in 6 months.

Since then I’ve been a believer that you give your developers nearly the fastest platform money can buy but then have automated, gatekeeping tests for your lowest target platform, with spot checking to make sure your tests reflect actual user experienced performance on that platform.

>management purposely prohibited developers from using really powerful machines because we needed to make the software faster.

at our BigCo these days we have a modern, dare i say Cloud Native, version of this stupidity - developers can't get even minimally powerful and reliably provisioned cloud resources (while the official rationale is similar to what you described the real one is much worse - it is just penny pinching). So it isn't just slow and unreliable, the real humongous cherry on top is that it has very short lifetime enforced by automatic deprovisioning - thus even when you finally were able to spin up our platform - which is far from guaranteed and may take many attempts as the platform is the product what we're developing, and it naturally has issues, etc. - and now you're happy and ready to start working on it, and at that moment it all disappears because of that short lifetime enforcing automated deprovisioning. Thus not surprisingly the results are exactly as you described - despite the management running around chanting cloud!cloud!cloud! our products' cloud story has so far made it practically nowhere .

I want a faster computer so that Visual Studio/MSVC compiles the code I write faster. I don't need a faster computer so that the application I develop runs faster. I'm already running an unoptomized debug build of our application which takes an order of magnitude of time longer to execute any given operation.

I live in a world where I cannot make performance evaluations based on my benchmarks on my "normal" build- I have to switch to a release build and recompile everything in order to make performance determinations. This led to my first personal experience of "premature optimization is the root of all evil". I implemented a new feature, performance was completely fucking untenably awful, so I threaded it. Performance was still awful, but it was 7x better because I has 7 free cores (8 total cores) to play with. I thought great, I tested, I found the bottleneck, I bandwidthed the fuuuck out the bottleneck, problem solved. A few weeks later I was testing on a release build, and in the same feature, the aforementioned bottleneck was using roughly 5% of the total CPU usage. Because the optimizer just - fixed all the slow stuff. The bottleneck that I threaded the shit out of didn't contribute significantly to the total CPU usage of the release build, while it was 87.5% or whatever of the debug build. And in the release build, I'm pretty sure all the threading overhead I added took away any and all benefit.

The thing I learned from that experience was to ignore all performance problems unless I observe them in a release build. If I had a faster computer, it would be significantly easier for me to switch back and forth between release and debug builds. And I would thus be able to observe performance problems easier.

I imagine there's a significant divide between front end web development and desktop application development here.

Your general point is of course correct, but “roughly 5% of total CPU usage of the release build” is absolutely worth fixing! As long as you fix it in the release build, not the debug build.

If you have a computer fast enough to do a release build quickly, it’s probably also fast enough to hide performance problems with the release build.

There are other approaches that can work, like building in the cloud so you don’t need a huge fast PC for each developer, or doing partially-optimized builds that balance build time with runtime (and debuggability).

Why would you use the debug build though? I routinely develop using release build only and only ever execute a debug build if I really have to drop into the debugger. U find that this gives me a better experience as it puts me closer to the actual end product in terms of UX and functionality in general. (I obviously still use things like asserts that are always built in even in my release build a so I don't skip on bug detection just because it's a release build)

I was the only one using Linux (read: sub-par HW acceleration coupled with less-beefy HW) with Chrome with a user-facing web-app at a previous employer. I noticed that the UI was janky on scroll, and when I opened DevTools/Rendering/Paint Flashing I realised everything was being repainted on scroll. The culprit ultimately was a JS library deep down in the frontend that had this unintended side-behaviour. None of the UI devs ever noticed it because on their 15" MBPs on OS X everything ran "smooth enough".

> the web would be a much better place if opening the Chrome developer tools automatically enabled the network throttler, and I think I’d have to agree with him.

This. And if it could also throttle CPU performance, painting performance, and available cache memory to a "typical user" profile that would be ideal.

It would be best of all if that typical profile varied from day to day to cover a range of experiences of typical users, but the distribution was updated periodically from the lower quartile of the general web user population as measured by surveys.

In general: Fast developer machine for builds, slow runtime machine for using the application.

(In embedded and console games this has always been automatic :-)

If you don't run the application on a separate machine, then simulate one instead.

But there's no advantage in making IDEs, compiles and testsuites run slowly. Just the target application.

It's not a unique opinion. It also depends on your role.

I'm not quite sure how much Apple shared publicly, but there was an iOS version that caused huge performance hit for older phones (honestly, it's kind of common with new major versions, but this was an outlier). They had a .5 release that tried to improve performance. My understanding is that, like you said, developers had been developing on the newest hardware. Apple seems to be more sensitive to this and it's not because performance for phones have plateaued, but I've noticed specific regressions here and there. I remember one iPhone specifically demoed how fast the camera launched. After a few OS updates the performance was as miserable as the phones they had been mocking.

I know console developers deal with this, too. Their SDK hardware has more RAM than production hardware, but their tools generally have big flashing alarms when you exceed the memory used in production.

I was around to get a peek at one of their "we need to make the OS faster and more stable" pushes and I recall engineers being told to do all their testing on the oldest, slowest iPhone still supported–everyone hated using them, of course, but when the finished product came out it was glorious how good it ran on even the oldest hardware. I get the impression that the last few releases this has been less emphasized. Performance is one way to tell this, of course, but another is that you'll notice the the UI of a lot of Apple's apps doesn't work well on smaller (and thus older) screens anymore ;)

I once had to debug an online service from a cruise ship. The network connection was painfully slow due to being over satellite. SSH is practically unusable with that latency. After suffering through that ordeal, I now take much greater care when developing software that requires internet access. Perhaps others could learn from this experience.

Yep, I had to deal with supporting an array of satnet devices and it was horrible, especially because the customers didn't understand that there was nothing we could do about clouds stopping their dashboard access...

I eventually helped design and deployed high quality LTE modems, which were awesome (with the right antennas, internet was good even in places where a phone would show no signal... but obviously the boonies on land are different than at sea!)

This is also part of the reason I am so cli/tui focused. I want to be able to run a full environment from ssh. (screen and mosh help with disconnects and instability)

You can enable local echo for SSH, which makes it quite usable even over latent connections.

I found mosh to be a huge improvement over standard SSH when connecting over roaming/unreliable/high latency networks.

Programmers should get whatever machine makes their build times tolerable, which probably means a pretty fast machine. Not because they are superior beings but just plain-old cost/benefit analysis.

Product managers and designers should use average equipment for their target market.

Your equipment should allow you to do your job better, not show your rank.

Engineering labor is so valuable to companies that if getting a software engineer whatever fancy machine they want makes them some fraction of a percent more productive then it’s already a good ROI.

The other thing to consider is that when you’re hiring software engineers, your competing with everybody else who’s also trying to hire software engineers. So if a candidate sees all your engineers using a laptop that they don’t want to use, they’re likely to take that into consideration when deciding whether they want to work for you. Expensive laptops, free food/drink, a gym, free massages, and all of those other perks you might find in software companies sound extravagant, but they’re such an easy and cost effective way to compete with other employers.

I think the “devs must have the latest hardware” meme expired probably a decade ago. Mid-range hardware is more than adequate for most devs to develop on without causing undue delays.

My work desktop is over 5 years old and still perfectly usable.

It's interesting, because developer tooling is subject to the very thing I mentioned too. The IDE I use the most often, Xcode, gets progressively worse to use on older hardware too because the engineers that work on it upgrade their computers to the latest as well. If your tooling has slower release cycles, your hardware can often hold out longer, but if you need to work with fast-moving tools you get to feel this pain yourself. It's really problematic because these policies have been around for quite a while now, so there are multiple levels of reasons pushing you towards the easy route of just buying faster hardware, which perpetuates the cycle even more.

Our Macs tend to be replaced in specific cycles, the same applies to the Windows laptops, regardless of what is hot in the market.

If we happen to get a customer laptop from their IT for accessing their internal network instead of some cloud instance, you can bet it is most likely fitted with 8GB and a regular HDD.

It is only on HN and Reddit bubbles that I get to see people using the very latest and greatest.

Ah, and I was part of a project a couple of years ago, where teams focused on Windows machines and literally timeshared iMacs and the respective iDevices for testing their hybrid apps.

Developer ergonomics is worth the cost to companies. Same reason standing desks, catered meals, gym, and other amenities are offered. Why not spend an extra $1000 or so over a few years for high end hardware?

I don't disagree with the notion that a developers experience using an application might be vastly different that of a regular user and that developers might forget the fact.

Then again, even if a developer cares about performance, if it's not set as the main goal or given any resources to pursue, it will still not get the much deserved attention.

Performance on lower grade consumer devices should absolutely be a minimum pass criterions, but if it isn't, giving developers older devices will not help.

I think it's important to have both (and indeed, do use both): a blazing-fast development machine for actually writing the code and a slow-as-molasses test machine (be it separate hardware or a heavily-handicapped VM on the fast machine) for dogfooding/testing the code. With the former, the faster the better; with the latter, the slower the better.

> I think the assumption that a company should outfit their developers with “the best” machines is problematic.

I’ve worked at several production companies, games & films, that had policies of giving devs the worst machines. The thinking being that artists who use the tools should always feel less pain than the devs who make the tools, not more.

In fairness the artists were probably editing and rendering assets that also required them to have very high spec machines too.

I half agree with you, that's why I always hesitated before upgrading to a new phone. A good approach is to explicitly encourage testing and require good performance on average hardware. There are many possible policies that help to achieve this goal, but forcing devs to develop on average hardware is too extreme.

Great point, but it's probably worth it if it accelerates development time, even by a little - or - makes devs. feel that their cool and that they are working at a 'good company'.

Not sure what that dollar figure looks like though.

I'm writing this on a 2011 Mac. Well maintained.

I disagree on many levels. I firmly think (being both a developer and a project lead) that the developers which build an application, should have the beefiest and fastest machine that money can buy. Especially if you want to have a fast product. Why is this?

- First of all, faster hardware means better productivity. If you want the developers have time to optimize for speed, better give them the time for this. Cutting their productivity usually means, less time is spend on optimizing, all "features" need to be implemented first. Only when all "features" have been implemented, quality improvements get scheduled. You want developers to be productive enough that they get time to improve quality/speed.

- Developers are running the application completely differently than the end users. If an application is run for hours if not even days at a time, startup speed doesn't count much. A developer might have to restart an application for debugging something every minute[1]. Having the developer waiting on startup would be a bad waste of time. While it might be nice to optimize startup times, the really might not be customer-relevant.

- Developers often run unoptimized code with debug code present or even inside a debugger. This makes the code often slower than the customer experience.

- Developers might have to run several instances of the application at the same time, requiring the neccessary compute resources, also the development environments need to be powered.

- And to some extend, which gets revived by the power of these new chips, development often happens years before a product ships. What is an exotic and expensive machine at the project start, might be a medium range for the customer when the product ships. So the development machine was actually a good match of the deployment platform.

These are some of the reasons why developers should have powerful machines. Of course, there are also a lot of reasons to test the product on less powerful machines and set performance goals according to these tests. But this doesn't mean the developer has to do the development work on those machines. If a product doesn't get tested enough and on the right systems, it is rather a project management issue.

1: I am fortunate to do quite a bit of my work in Lisp and it is one huge productivity boost that I can update every single function redefinition in the running code. Which gives me increadibly short iteration cycles. The cost of starting up an application to test a change isn't just the startup time but also the interaction needed until you get to the point where the function is called, I am doing quite UI-centric work. This becomes very noticable, whenever I actually have to restart the application to get a meaningful test. Even worse are the situations where I even have to wait for a longer compilation run (with non-Lisp languages, like C++)