One note, the extra memory in the 128GB model is directly usable for locally-running LLM models
Tracking developer build times to decide if the M3 MacBook is worth upgrading
161–170 of 432 posts
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#162As a scientist, I'm interested how computer programmers work with data. * They drew beautiful graphs! * They used chatgpt to automate their analysis super-fast! * ChatGPT punched out a reasonably sensible t test! But: * They had variation across memory and chip type, but they never thought of using a linear regression. * They drew histograms, which are hard to compare. They could have supplemented them with simple me…
> They drew histograms, which are hard to compare.
Like you, I'd suggest empirical CDF plots for comparisons like these. Each distribution results in a curve, and the curves can be plotted together on the same graph for easy comparison. As an example, see the final plot on this page:
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#163I feel like there is a correlation between fast-twitch programming muscles and technical debt. Some coding styles that are rewarded by fast compile times can be more akin to "throw it at the wall, see if it sticks" style development. Have you ever been summoned to help a junior colleague who is having a problem, and you immediately see some grievous errors, errors that give you pause. You point the first couple out,…
Slow build times make everything slower, including refactoring tech debt (which means people are less likely to do it).
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#164If you are working at home why bother with a laptop? You can get a much more powerful desktop for the same price.
Threadripper away, most folks are sent a machine by their company tho
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#165Solid 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.…
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?
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#166Does anyone have any anecdoctal evidence around the snappiness of VsCode with Apple Silicon? I very begrudgingly switched over from SublimeText this year (after using it as my daily driver for ~10yrs). I have a beefy 2018 MBP but VScode just drags. This is the only thing pushing me to upgrade my machine right now but I'd be bummed if there's still not a significant improvement with an m3 pro.
If you find your compiles are slow, I found a bug in vscode where builds would compile significantly faster when the status bar and panel are hidden. Compiles that took 20s would take 4s with those panels hidden. https://github.com/microsoft/vscode/issues/160118
That was a year ago! At this point someone will complain that it’s a feature they use to warm their cat.
Not every day one sees a user report a 5x performance issue that seems so simple to reproduce.
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#167Earlier 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?
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
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#168If 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?
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#169MacBooks are a waste of money. You can be just as productive with a machine just as fast for 1/2 the price that doesn't include the Apple Tax. Moreover, if your whole stack (plus your test suite) doesn't fit in memory, what's the point of buying an extremely expensive laptop? Not to mention constantly replacing them just because a newer, shinier model is released? If you're just going to test one small service, that…
[deleted]
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#170I feel like there is a correlation between fast-twitch programming muscles and technical debt. Some coding styles that are rewarded by fast compile times can be more akin to "throw it at the wall, see if it sticks" style development. Have you ever been summoned to help a junior colleague who is having a problem, and you immediately see some grievous errors, errors that give you pause. You point the first couple out,…
Slow build times make everything slower, including refactoring tech debt (which means people are less likely to do it).
I didn't say faster build times weren't faster. I said people whose entire focus is on speed will speed-read the cliff notes instead of fully reading the original Shakespeare. There's a difference.