Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tracking developer build times to decide if the M3 MacBook is worth upgrading

incident.io

Post reply on HN
Print view View original

171–180 of 432 posts

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#171

Post by kaishiro »

avbor wrote: post #167
kaishiro wrote: post #165

Earlier quoted context omitted.

One thing I've never understood (and admittedly have not thoroughly researched) is how a remote workspace jives with front-end development. My local tooling is all terminal-based, but after ssh'ing into the remote box to conduct some "local" development, how do I see those changes in a browser? Is the local just exposed on an ip:port?

You can expose the browser port via ssh, with a command line flag like `-L 8080:127.0.0.1:8080`. So you can still preview locally

Ah yeah, tunneling it back makes perfect sense - not sure why I never considered that. I'll explore that a bit - thanks for the heads up!

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#173

Post by fragmede »

kaishiro wrote: post #165
rsanek wrote: post #137

Earlier quoted context omitted.

This might have to do with scale. At my employer (~7k employees) we started down this path a few years ago as well, and while it has taken longer for remote to be better than local, it now definitively is and has unlocked all kinds of other stuff that wasn't possible with the local-only version. One example is working across multiple branches by switching machines instead of files on local has meant way lower latency…

One thing I've never understood (and admittedly have not thoroughly researched) is how a remote workspace jives with front-end development. My local tooling is all terminal-based, but after ssh'ing into the remote box to conduct some "local" development, how do I see those changes in a browser? Is the local just exposed on an ip:port?

Yes, modulo networking VPN magic so it's not available over the wider Internet for hackers to discover.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#174

Post by whalesalad »

hmottestad wrote: post #159
whalesalad wrote: post #42

Earlier quoted context omitted.

I have a rack in my basement with a combined 96 cores and 192gb of ram (proxmox cluster), and a 13900k/64gb desktop workstation for most dev work. I usually will offload workloads to those before leveraging one of these old laptops that is usually dead battery. If I need something for "browser tasks" (I am interpreting this as cross-browser testing?) I have dedicated VMs for that. For just browsing the web, my M2 is…

I went the complete opposite of you. I enjoy being able run everything on my laptop, be it at home, at a cafe, at work or on the train. So I’ve maxed out a MacBook Pro instead. It doesn’t have 96 cores, but it’ll go head to head with your dev workstation and even let me play around with LLMs locally. Fans as usually silent, except when using the GPU for LLMs. One thing that I could do with your rig though would be to…

Tailscale helps here. I run all my stuff remotely and just reconnect my shell with tmux, and vscode reconnects automatically. The only area this hurts is on an airplane. I was in Germany recently and still developed remotely using my workstation as the compute. It was super quick with no discernible latency. My laptop is essentially a dumb terminal. It could get stolen or run over by a truck and I’d be back in business after installing tmux and Tailscale.

I’ve replayed this pattern with other targets, too. For instance a system I maintain relies on a whitelisted IP in our VPC to interact with certain API’s at a vendor. I could proxy to that node and use that IP, but I’ve found it much easier to hack on that project (running on a dedicated EC2 node) by just vscode attaching there, using it live, and committing the changes from the end server running the system.

Being able to kill my laptop and know everything is still running remotely is nice. I rely on tmux heavily.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#175

Post by sweetjuly »

dmos62 wrote: post #155
LASR wrote: post #90

Solid analysis. A word of warning from personal experience: I am part of a medium-sized software company (2k employees). A few years ago, we wanted to improve dev productivity. Instead of going with new laptops, we decided to explore offloading the dev stack over to AWS boxes. This turned out to be a multi-year project with a whole team of devs (~4) working on it full-time. In hindsight, the tradeoff wasn't worth it.…

My dev box died (that I used for remote work), and instead of buying something new immediately, I moved my setup to a Hetzner cloud vps. Took around 2 days. Stuff like setting up termux on my tablet and the cli environment on the vps was 90 percent of that. The plus side was that I then spent the remaining summer working outside in the terrace and in the park. Was awesome. I was able to do it because practically all…

How much does this cost you? I've been dealing with a huge workstation-server thing for years in order to get this flexibility and while the performance/cost is amazing, reliability and maintenance has been a pain. I've been thinking about buying some cloud compute but an equivalent workstation ends up being crazy expensive (>$100/mo).

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#176

Post by FpUser »

faeriechangling wrote: post #168
postalrat wrote: post #160

If you are working at home why bother with a laptop? You can get a much more powerful desktop for the same price.

What if you don't need a much more powerful desktop? What if you get more utility from being able to move the computer around at least occasionally?

For "occasional move" I have small factor desktop. It is relatively tiny but still has 16 cores AMD and 128GB RAM.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#177

Post by perrygeo »

mdbauman wrote: post #103
jiggawatts wrote: post #97

Earlier quoted context omitted.

https://xkcd.com/1205/

This xkcd seems relevant also: https://xkcd.com/303/ One thing that jumps out at me is the assumption that compile time implies wasted time. The linked Martin Fowler article provides justification for this, saying that longer feedback loops provide an opportunity to get distracted or leave a flow state while ex. checking email or getting coffee. The thing is, you don't have to go work on a completely unrelated task.…

Yes! Pauses allow you to reflect on your expectations of what you're actually compiling. As you sit in anticipation, you reflect on how your recent changes will manifest and how you might QA test it. You design new edge cases to add to the test suite. You sketch alternatives in your notebook. You realize oh compilation will surely fail on x because I forgot to add y to module z. You realize your logs, metrics, tests and error handling might need to be tweaked to unearth answers to the questions that you just now formulated. This reflection time is perhaps the most productive time a programmer will spend in their day. Calling it "wasted" reflects a poor understanding of the software development process.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#179

Post by norir »

mdbauman wrote: post #103
jiggawatts wrote: post #97

Earlier quoted context omitted.

https://xkcd.com/1205/

This xkcd seems relevant also: https://xkcd.com/303/ One thing that jumps out at me is the assumption that compile time implies wasted time. The linked Martin Fowler article provides justification for this, saying that longer feedback loops provide an opportunity to get distracted or leave a flow state while ex. checking email or getting coffee. The thing is, you don't have to go work on a completely unrelated task.…

I get what you are saying but I still think fast compilation is essential to a pleasant dev experience. Regardless of how fast the compiler is, there will always be time when we are just sitting there thinking, not typing. But when I am implementing, I want to verify that my changes work as quickly as possible and there is really no upside to waiting around for two minutes.
Post reply on HN