4 ms·
If you think developers churn out code at maximum productivity throughout the day and a 10m improvement in compile times per day will reap you benefits in a yea
by rootlocus 8y ago
If you think developers churn out code at maximum productivity throughout the day and a 10m improvement in compile times per day will reap you benefits in a year, you're sorely mistaken. Unless that improvement lowers the compile time below a certain threshold where the dev will say "fuck it, I'll read some HN while it builds" you're probably not gaining anything.
- hrktb 8y agoI think there is more to it than pure compile time. It can affect responsiveness enough that it becomes disturbing. From there it can mean using fewer plugins, disabling part of the static code checks, doing less full debugging etc. I remember how activating the debugging flags wouldn’t work on some projects as the machine couldn’t handle it memory wise. All of these have a compounding effect that is non trivial.
- benj111 8y agoAh but then that dev comes across an insightful article, that changes how they think about programming, and becomes a better programmer. What we should really be doing is spending all our time 'researching' on the internet. Increasing our value to our companies. That's what I tell my boss anyway.
- nickpsecurity 8y agoThe original argument I read was that slowdowns or waits past a certain time affect mental flow. The flow is basically you being in the zone coding optimally. Interruptions like phones can jolt a person out of flow. So can long wait times. If person is in flow, you want them cranking out as much output as they can with no slowdowns. That was an advantage of Smalltalk and LISP. Any language with REPL or IDE supporting something like it will let one do this.