Re:Facts every web dev should know before they burn out and ...
by selfhoster11 on Thursday October 21, 2021 @06:03AM
(#28942396)
> I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.
Re:Facts every web dev should know before they burn out and ...
by rightbyte on Thursday October 21, 2021 @05:40AM
(#28942267)
I don't get the initial short build time thing. My prior work project took 15h too build from clean - obviously a nightmare. It was due to bad layout of dependencies and a lot of generation. So it is still important to not mess up.
I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
Re:Facts every web dev should know before they burn out and ...
by selfhoster11 on Thursday October 21, 2021 @06:02AM
(#28942382)
With a bad enough (or just unfortunate) codebase or technology choices, every build could easily turn into a full build. I care about cold build and cold restart times exactly for this reason.
Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment.
I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.