Live data from Hacker News

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

incident.io

221–230 of 432 posts

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

#221
post #191
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 team has been developing against a fully remote environment (K8s cluster) for some years now and it makes for a really powerful DevEx. Code sits on our laptops but live syncs to the remote services without requiring a Docker build or K8s deploy. It really does feel like local. In particular it lets us do away with the commit-push-pray cycle because we can run integ tests and beyond as we code as opposed to waiting…

I tried Garden briefly but didn't like it for some reason. DevSpace was simpler to set up and works quite reliably. The sync feature where they automatically inject something into the pod works really well.

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

#222
post #214
post #191

Earlier quoted context omitted.

My team has been developing against a fully remote environment (K8s cluster) for some years now and it makes for a really powerful DevEx. Code sits on our laptops but live syncs to the remote services without requiring a Docker build or K8s deploy. It really does feel like local. In particular it lets us do away with the commit-push-pray cycle because we can run integ tests and beyond as we code as opposed to waiting…

Kind of interesting to think that CI is significantly slower in practice and both systems need to be maintained. Is it just the overhead of pushing through git or are there other reasons as well?

You would need a very perfect and flexible CI system in place that wouldn't need to rebuild anything it doesn't need and only run the tests you want or only recently failed tests etc.

Many CI systems would spin up a new box instead of using persistent so likely have to rebuild if no cache, etc.

So basically I would say most of the overhead is in not having a persistent box with knowledge of last build or ability to choose what to run in there, which pretty much just equals to local capabilities.

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

#223
I am ex-core contributor Chromium and Node.js and current core contributor to gRPC Core/C++.

I am never bothered with build times. There is "interactive build" (incremental builds I use to rerun related unit tests as I work on code) and non-interactive build (one I launch and go get coffee/read email). I have never seen hardware refresh toggle non-interactive into interactive.

My personal hardware (that I use now and then to do some quick fix/code review) is 5+ year old Intel i7 with 16Gb of memory (had to add 16Gb when realized linking Node.js in WSL requires more memory).

My work laptop is Intel MacBook Pro with a touch bar. I do not think it has any impact on my productivity. What matters is the screen size and quality (e.g. resolution, contrast and sharpness) and storage speed. Build system (e.g. speed of incremental builds and support for distributed builds) has more impact than any CPU advances. I use Bazel for my personal projects.

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

#224
post #144

> All developers work with a fully fledged incident.io environment locally on their laptops: it allows for a This to me is the biggest accomplishment. I've never worked at a company (besides brief time helping out with some startups) where I have been able to run a dev/local instance of the whole company on a single machine. There's always this thing, or that, or the other that is not accessible. There's always a got…

I never couldn't run the damn app locally until my latest job. Drives me bonkers. I don't understand how people aren't more upset and this atrocious devex. Damn college kids don't know what they're missing.

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

#225
post #10

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

You have a 5-year old computer.

I'm a professional and I make a living writing software. Investing ~4k every 3-4 years on fast computer is a no brainer to me.

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

#226
To play devil’s advocate: did you see any improvement in ticket velocity, features shipped, bugs dispatched, prod events resolved - i.e. is this improvement in productivity measurable by what you judge the business by, or does it just feel better and make devs happy?

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

#227
post #63

Earlier quoted context omitted.

The M3 Pro being nerfed has been parroted on the Internet since the announcement. Practically it’s a great choice. It’s much more efficient than the M2 Pro at slightly better performance. That’s what I am looking for in a laptop. I don’t really have a usecase for the memory bandwidth…

The M3 Pro and Max get virtually identical results in battery tests, e.g. https://www.tomsguide.com/news/macbook-pro-m3-and-m3-max-bat... . The Pro may be a perfectly fine machine, but Apple didn't remove cores to increase battery life; they did it to lower costs and upsell the Max.

It might be the case that the yield on the chips is low, so they decided to use “defective” chips in the M3 Pro, and the non-defective in the M3 Max.

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

#228
post #223

I am ex-core contributor Chromium and Node.js and current core contributor to gRPC Core/C++. I am never bothered with build times. There is "interactive build" (incremental builds I use to rerun related unit tests as I work on code) and non-interactive build (one I launch and go get coffee/read email). I have never seen hardware refresh toggle non-interactive into interactive. My personal hardware (that I use now and…

Somehow programmers have come to accept that a minuscule change in a single function that only result in a few bytes changing in a binary takes forever to compile and link. Compilation and linking should be basically instantaneous. So fast that you don't even realize there is a compilation step at all.

Sure, release builds with whole program optimization and other fancy compiler techniques can take longer. That's fine. But the regular compile/debug/test loop can still be instant. For legacy reasons compilation in systems languages is unbelievably slow but it doesn't have to be this way.

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

#229
post #223

I am ex-core contributor Chromium and Node.js and current core contributor to gRPC Core/C++. I am never bothered with build times. There is "interactive build" (incremental builds I use to rerun related unit tests as I work on code) and non-interactive build (one I launch and go get coffee/read email). I have never seen hardware refresh toggle non-interactive into interactive. My personal hardware (that I use now and…

Aren’t M series screen and storage speed significantly superior to your Intel MBP? I transitioned from an Intel MBP to M1 for work and the screen was significantly superior (not sure about storage speed, our builds are all on a remote dev machine that is stacked).

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

#230
My problem with this analysis is ignoring the fact of who is using which computer. So far new people in the company get the M3, while old people have M2, and the people who has been the longest time in the company have an M1. Who is going to work on more critical tasks with more changes in the code? who is going to work mostly in easy bugs until they get some experience with the code in the company? I bet you if you give both populations the same computer the compiling times are going to be faster for the new people. For me the analysis doesn't have enough dimensions, it should take into account the time since the person was hired in the company and the seniority. I would also have added more type of graphs (boxplots seems a better way to compare the information), and also I would have measure the total % of CPU usage. The battery/AC analysis gave me the impression that M3 might be underutilized and that it is going to be impossible to get lower compiling times without faster single core speeds (which might be a relevant information for the future).
Post reply on HN